• mitschke (unregistered)

    But exec is so temting easy sometimes....

  • KittyKat (unregistered)

    Wouldn;t it been safer and better to add a custom php addin?

  • Tim (unregistered)

    Dear God,

    Please kill PHP.

    Sincerely,

    Everyone except PHP programmers (and VB programmers).

  • Hivemind (unregistered)

    I'm an IT geek whose primary language is PHP ducks Though I've never done anything like this, I at least know when to NOT use PHP. For shell scripting - yes, anything browser-based - ok. but that? hell no.

    sigh

  • g0ats3 (unregistered)

    5th!!!!!!1111!!555%%555five

  • (cs)

    This comment on php-driven raid controllers beep is being written because Beep it is important to note that BEEP php may not be the best choice for this purpo... Plug yanked

  • Mii (unregistered)

    I'm a PHp programmer.. and I actually didn't recognize that as PHP...

    And yes.. I agree.. kill PHP please.. now that decided to use the \ as namespace separator I really wanne quit it :S

  • Bob (unregistered)

    It always scares me when I meet engineers who program. Think of all the firmware code out there. And what it does.

  • Jason Felice (unregistered)

    My favorite part is definitely:

    $new_str .= sprintf("%s", $str);
  • Ken (unregistered)

    oh... my... god.

    that's worse than the LSI Logic RAID util code I had to work on last summer as an intern. Here I was thinking that was the worst code I would ever see...

  • Bobble (unregistered)

    I think there is a CTO that deserves a beating somewhere.

  • (cs) in reply to Jason Felice
    Jason Felice:
    My favorite part is definitely: 
    $new_str .= sprintf("%s", $str);

    Well, it's better than:

        $new_str .= sprintf($str);
  • Richard (unregistered)

    Actually, PHP-CLI is quite a decent scripting language for general purpose use. In many cases, it's interchangeable with perl. Given that the LCD control probably requires just a bit of simple "glue", and some re-formatting, and most likely has a serial port interface, I can't see anything wrong with using PHP here. If the performance is bad, it's probably not PHP that's really to blame, but one of the underlying programs.

    For what it's worth, I do use PHP extensively, and (at the risk of thinking that, if all you have is a hammer, everything looks like a nail), I've used it for simple hardware interfacing myself.

  • Anonymous (unregistered)

    RAID controller firmware is definitely not a personal home page. And even if it was, I'd still question the use of PHP.

  • mauhiz (unregistered)

    exec('echo "This is a comment"' > mycomment && wget --post-data mycomment "http://thedailywtf.com/Comments/AddComment.aspx?ArticleID=6348"');

  • Alex (unregistered) in reply to Richard
    Richard:
    Actually, PHP-CLI is quite a decent scripting language for general purpose use. In many cases, it's interchangeable with perl. Given that the LCD control probably requires just a bit of simple "glue", and some re-formatting, and most likely has a serial port interface, I can't see anything wrong with using PHP here. If the performance is bad, it's probably not PHP that's really to blame, but one of the underlying programs.

    For what it's worth, I do use PHP extensively, and (at the risk of thinking that, if all you have is a hammer, everything looks like a nail), I've used it for simple hardware interfacing myself.

    Isn't that like using paper glue to try and tie two pieces of PVC pipe together ?

  • relaxing (unregistered)

    please, please tell me what company this is so i can not buy their products...

  • PHP Programmer (unregistered)

    http://www.php.net/manual/en/function.str-pad.php

  • (cs) in reply to SlyEcho
    SlyEcho:
    Jason Felice:
    My favorite part is definitely: 
    $new_str .= sprintf("%s", $str);

    Well, it's better than:

        $new_str .= sprintf($str);

    Don't worry, at least PHP's sprintf is safe from format string attack.

  • (cs)

    exec("killall php");

  • (cs)

    WTF for does an LCD controller module write events to log? Shouldn't it, like, control the LCD and let other parts of the system do the logging and whatnot?

  • (cs) in reply to Tim
    Tim:
    Dear God,

    Please kill PHP.

    Sincerely,

    Everyone except PHP programmers (and VB programmers).

    Ha ha, I get it. You're an elitist programmer. You probably only know C on BSD or Linux, spell "Windows" with a Z, and laugh at "User Friendly." You do a little web programming in Perl, but dismiss its inferiorities as being part of a "more powerful" scripting language "not for MC$E idiots." Your fatal slip was attacking VB and PHP in the same sentence, whereas they are two totally different languages and, for one, PHP is actually cross-platform. Ha ha, I and every other quasi-programmer who even knows how to spell PHP should kill ourselves. That's hilarious. I can't wait to hear your splendid C-pound material.

  • Ted (unregistered)

    "... not quite what PHP was designed for."

    PHP was designed?

  • Matt (unregistered) in reply to operagost
    operagost:
    Tim:
    Dear God,

    Please kill PHP.

    Sincerely,

    Everyone except PHP programmers (and VB programmers).

    Ha ha, I get it. You're an elitist programmer. You probably only know C on BSD or Linux, spell "Windows" with a Z, and laugh at "User Friendly." You do a little web programming in Perl, but dismiss its inferiorities as being part of a "more powerful" scripting language "not for MC$E idiots." Your fatal slip was attacking VB and PHP in the same sentence, whereas they are two totally different languages and, for one, PHP is actually cross-platform. Ha ha, I and every other quasi-programmer who even knows how to spell PHP should kill ourselves. That's hilarious. I can't wait to hear your splendid C-pound material.

    Wow. Who made you king jack-ass?

  • (cs) in reply to Ted
    Ted:
    "... not quite what PHP was designed for."

    PHP was designed?

    Absolutely. By about 5000 different people with completely different ideas.

  • bla (unregistered) in reply to Ted
    Ted:
    "... not quite what PHP was designed for."

    PHP was designed?

    You made my day :-)

  • idan (unregistered) in reply to Ted

    sprintf("I agree.");

  • EatenByAGrue (unregistered) in reply to Ted
    Ted:
    "... not quite what PHP was designed for."

    PHP was designed?

    No, it was congealed.

    And this whole article can be filed under "use the right tool for the job". Having been subjected to PHP in previous jobs, it's semi-tolerable for web apps, but worse than useless in most other contexts.

  • Chiper (unregistered) in reply to Evo
    Evo:
    PHP was designed?
    Absolutely. By about 5000 different people with completely different ideas.
    Each of them coming and going over the course of, what, ten years? PHP has more depreciated function calls and features then any other language I've ever used.

    But I still love it, because it's easier to work with then JSP, and cheaper to deploy then ASP.

  • (cs) in reply to tdb
    tdb:
    WTF for does an LCD controller module write events to log? Shouldn't it, like, control the LCD and let other parts of the system do the logging and whatnot?

    No, it doesn't handle logging. The log daemon is written in C -- but running 'strings' on it reveals that it abuses 'exec' just as much:

    $ strings qlogd
...
/bin/umount -f %s >/dev/null 2>&1
/sbin/e2fsck -p %s >/dev/null 2>&1
/bin/mount -t ext3 %s %s >/dev/null 2>&1
/sbin/mke2fs -j -b 4096 %s >/dev/null 2>&1
...
ifconfig eth0 | awk '/inet addr:/{print $2}' | awk -F: '{print $2}'
...
/usr/bin/snmptrap -v 1 -c %s %s %s %s 6 %d ""  %s s "%s"
...
%s %s: "%s" "%s" "%s" "%s" "%d" "%s" "%s" "%s" >/dev/null 2>&1
  • (cs)

    Not clear what he means by "due in no small part to the kernel module, exec() is slow", but if he's loading and unloading the module on demand, try not doing that.

  • Matthew (unregistered) in reply to Richard
    Richard:
    For what it's worth, I do use PHP extensively, and (at the risk of thinking that, if all you have is a hammer, everything looks like a nail), I've used it for simple hardware interfacing myself.

    In this case PHP is the hammer, and the problem is a screw. Yeah if you bang hard enough it will work, but a Screwdriver (C) or even a powerdrill (Python) would work much better :)

  • SomeCoder (unregistered)

    I've seen this sort of thing a lot. In fact, I know people who actively do it, though not to this degree, certainly.

    Because PHP has the CLI interface, everyone thinks that it's great for writing applications.

    PHP may not stand for Personal Home Page anymore, but that doesn't mean it's a good language to use to interface with hardware.

    I like PHP for web stuff but this kind of abuse is just... gah.

  • Yep (unregistered) in reply to Matthew
    Matthew:
    Richard:
    For what it's worth, I do use PHP extensively, and (at the risk of thinking that, if all you have is a hammer, everything looks like a nail), I've used it for simple hardware interfacing myself.

    In this case PHP is the hammer, and the problem is a screw. Yeah if you bang hard enough it will work, but a Screwdriver (C) or even a powerdrill (Python) would work much better :)

    Haha.. Python.. a power drill. That's a good one. You almost had me believing that you were serious.

  • Robert Englewood (unregistered) in reply to Chiper
    Chiper:
    PHP has more depreciated function calls and features then any other language I've ever used.
    Oh sure, these other function calls might be worth half of what they used to, but you can't really expect to get retail price after they're standardized anyway.
  • rycamor (unregistered)

    Well now, it could have been worse. They could have hosted Windows inside a virtual machine and then run an instance of ASP.NET, with the backend calls being implemented as emails to the host (Linux?) OS.

    Or Ruby on Rails (ducks flamewar).

    Seriously, I have perpetrated a few PHP atrocities (although I at least coded them better), but never in my wildest most desperate imaginings would I use PHP on firmware. The only scripting language I see as being appropriate for firmware might possibly be Lua, but honestly, if you're going to the trouble, why not just code it in C? It's FIRMWARE. The whole concept of firmware runs completely counter to the idea of scripting languages.

  • Anon Ymous (unregistered) in reply to Yep
    Yep:
    Matthew:
    Richard:
    For what it's worth, I do use PHP extensively, and (at the risk of thinking that, if all you have is a hammer, everything looks like a nail), I've used it for simple hardware interfacing myself.

    In this case PHP is the hammer, and the problem is a screw. Yeah if you bang hard enough it will work, but a Screwdriver (C) or even a powerdrill (Python) would work much better :)

    Haha.. Python.. a power drill. That's a good one. You almost had me believing that you were serious.

    Python is a football bat.

  • James (unregistered)

    OK, I have one question about the very last code snippet: if exec'ing was wrong to get the IP of eth0 (specifically eth0, not just "any old network"), what's the right way to do it? I've been looking for just that kind of information lately...

  • (cs) in reply to rycamor
    rycamor:
    The only scripting language I see as being appropriate for firmware might possibly be Lua,

    YES. Thank you. If I had actually designed the blasted thing, I would use Lighttpd and Lua. Lua is faster than PHP or even Python (which is still much better than PHP). A scripting language is fine for things like the web UI.

    Bad programmers can write PHP in any language, though.

  • rycamor (unregistered) in reply to jspenguin
    jspenguin:
    A scripting language is fine for things like the web UI.

    Except for the part about it being a custom kernel module. Again, if you are going to go to the trouble of building a kernel module... in C...?

    jspenguin:
    Bad programmers can write PHP in any language, though.

    I like that one, and I'm going to use it.

  • (cs)

    Well, at least all of the exec's appear to be abstracted into centralized functions. Think how much worse it would be if the code was peppered with exec('ipconfig ...') all over the place.

  • (cs) in reply to James
    James:
    OK, I have one question about the very last code snippet: if exec'ing was wrong to get the IP of eth0 (specifically eth0, not just "any old network"), what's the right way to do it? I've been looking for just that kind of information lately...
    struct ifreq req;
int fd = socket(AF_INET, SOCK_STREAM);

strcpy(req.ifr_ifrn.ifrn_name, "eth0");
ioctl(fd, SIOCGIFADDR, &req)
return inet_ntoa(((struct sockaddr_in*)req.ifr_ifru.ifru_addr).in_addr);

    It would be easy to code a wrapper function for PHP that does that. They already have several custom native functions that allow the PHP web UI to manage the RAID.

    Even still, the command is a pipeline that starts three processes, when it could just start one ("ifconfig eth0") and parse the output text itself instead of using awk and grep. That's what my replacement function does.

    And calling "grep" just to find out if a file contains a certain line -- well that's just pure laziness and stupidity.

  • Zach Bora (unregistered)
    http://ca.php.net/manual/en/preface.php:
    http://ca.php.net/manual/en/preface.php PHP, which stands for "PHP: Hypertext Preprocessor" is a widely-used Open Source general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. Its syntax draws upon C, Java, and Perl, and is easy to learn. The main goal of the language is to allow web developers to write dynamically generated web pages quickly, but you can do much more with PHP.

    the sky is the limit!

  • (cs) in reply to rycamor
    rycamor:
    jspenguin:
    A scripting language is fine for things like the web UI.

    Except for the part about it being a custom kernel module. Again, if you are going to go to the trouble of building a kernel module... in C...?

    I think you misunderstand. The kernel module is not written in PHP. My brain would explode if it was.

    The RAID module (sansoft.o) is written in C, but it's so poorly written that it slows down the entire system. It creates a kernel thread called "SCHED" that constantly uses 97% of the CPU.

    If I boot with a stripped down firmware that doesn't load the module, everything runs snappy.

  • Bored Bystander (unregistered) in reply to Chiper
    Chiper:
    ...snip... PHP has more depreciated function calls and features then any other language I've ever used. ...snip...

    Give it a while, Python will definitely have more.

  • rycamor (unregistered) in reply to jspenguin
    jspenguin:
    rycamor:
    jspenguin:
    A scripting language is fine for things like the web UI.

    Except for the part about it being a custom kernel module. Again, if you are going to go to the trouble of building a kernel module... in C...?

    I think you misunderstand. The kernel module is not written in PHP. My brain would explode if it was.

    No, I understood that, but I was under the impression that the PHP/Apache runtime was a custom kernel module. In other words, someone still had to go to the trouble of mucking around with C and compiling, just to get the scripting environment.

    Or am I wrong about that also?

  • (cs) in reply to rycamor
    rycamor:
    jspenguin:
    I think you misunderstand. The kernel module is not written in PHP. My brain would explode if it was.

    No, I understood that, but I was under the impression that the PHP/Apache runtime was a custom kernel module. In other words, someone still had to go to the trouble of mucking around with C and compiling, just to get the scripting environment.

    Or am I wrong about that also?

    The kernel module is just for the RAID. The http daemon (I think it's called mini_httpd) runs in userspace, and uses plain old CGI to interface with PHP. The PHP binary is definitely customized, as I said before, since they have functions that interface with the RAID module (probably through ioctls on some device -- I haven't disassembled anything). Apparently, they don't know how to use standard IOCTLs, though.

    Also, because each PHP CGI request involves forking and execing, the web UI is slow as crap. And perhaps the biggest WTF is that using the web UI can actually slow down transfer speeds - over Ultra320 SCSI. And, since the web UI automatically refreshes every 10 seconds or so, even having the config UI open can slow down transfers.

  • (cs) in reply to Matthew
    Matthew:
    Richard:
    For what it's worth, I do use PHP extensively, and (at the risk of thinking that, if all you have is a hammer, everything looks like a nail), I've used it for simple hardware interfacing myself.

    In this case PHP is the hammer, and the problem is a screw. Yeah if you bang hard enough it will work, but a Screwdriver (C) or even a powerdrill (Python) would work much better :)

    Ha, heh, heh... you said "screw",... heh, heh, ha... and "bang".

  • (cs) in reply to jspenguin
    jspenguin:
    James:
    OK, I have one question about the very last code snippet: if exec'ing was wrong to get the IP of eth0 (specifically eth0, not just "any old network"), what's the right way to do it? I've been looking for just that kind of information lately...
    struct ifreq req;
int fd = socket(AF_INET, SOCK_STREAM);

strcpy(req.ifr_ifrn.ifrn_name, "eth0");
ioctl(fd, SIOCGIFADDR, &req)
return inet_ntoa(((struct sockaddr_in*)req.ifr_ifru.ifru_addr).in_addr);

    It would be easy to code a wrapper function for PHP that does that. They already have several custom native functions that allow the PHP web UI to manage the RAID.

    Even still, the command is a pipeline that starts three processes, when it could just start one ("ifconfig eth0") and parse the output text itself instead of using awk and grep. That's what my replacement function does.

    And calling "grep" just to find out if a file contains a certain line -- well that's just pure laziness and stupidity.

    It's been a VERY long time since I've used "C", but I am quite certain it doesn't garbage collect connections; shouldn't you also close the socket?

    If you're going to show someone how to do something, please go all the way!

  • rycamor (unregistered) in reply to jspenguin
    jspenguin:

    The kernel module is just for the RAID. The http daemon (I think it's called mini_httpd) runs in userspace, and uses plain old CGI to interface with PHP. The PHP binary is definitely customized, as I said before, since they have functions that interface with the RAID module (probably through ioctls on some device -- I haven't disassembled anything). Apparently, they don't know how to use standard IOCTLs, though.

    Also, because each PHP CGI request involves forking and execing, the web UI is slow as crap. And perhaps the biggest WTF is that using the web UI can actually slow down transfer speeds - over Ultra320 SCSI. And, since the web UI automatically refreshes every 10 seconds or so, even having the config UI open can slow down transfers.

    So my argument still stands. They had to install an httpd daemon, and customize and compile their own PHP binary, which still pretty much begs the question of using a scripting language. Not to mention, they used CGI?? And auto-refreshes... gahh!! The more I hear, the more WTF I see. Really, the simple fact that PHP was used is the least of the WTFs here.

Leave a comment on “Raiding the RAID”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article