dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
3
share rss forum feed


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23
reply to Bill_MI

Re: Why ever use a hard link?

I'ma regular contributor to the TomatoUSB firmware, so I have more than enough familiarity with Busybox.

squashfs is partially the reason Busybox is used this way. To clarify, squashfs supports both hardlinks and symlinks. Further proof is in this incorrect problem report. Hardlinks could have been used just as effectively -- and in some firmwares they are used instead of symlinks. What I do not know is what the compression level difference is between a symlink and a hardlink with squashfs. It varies based on inode type (dir vs. file vs. symlink vs. hardlink vs. FIFO etc.), so there may be an advantage compression-wise to using symlinks over hardlinks.

From the Busybox perspective it doesn't matter though -- the main busybox binary itself parses argv[0] and iterates over a large array of strings, comparing against the effective calling command was. Rather than get into the parsing semantics, it works like this: if you symlink or hardlink "poop" to the busybox binary, and you run the "poop" command, the busybox binary compares the command you run to argv[0] and if it finds a match, it runs the code associated for that command. If there is no match, I believe busybox spits back some error like "unsupported command".

This is exactly what FreeBSD's /rescue/rescue does too, it's just done (implemented) differently internally -- the binaries you see that are hard linked to /rescue/rescue are not "custom versions" like what you find with Busybox -- they are the real deal.

So there's a single binary on the system that handles lots of commands. Why is it done this way? That has to do with saving space on a filesystem like squashfs, quite simply. Remember: Busybox "markets" itself for embedded environments or where space is very limited.

{opinion}
Other than that, Busybox is just a total piece of utter junk. I cannot even begin to explain to you the amount of bugs and brokenness that are in this suite. I think my bug list, personally experienced, is up to 40 or 50 by now, and I have fixed my own share of catastrophic bugs in that junkpile more than once (my favourites usually consist of file descriptor leakage, i.e. someone not calling close() but repeatedly calling open()). A colleague of mine personally knows a developer who quit the Busybox team after several years, simply because of how utterly horrible the code was that was being pushed out. That fellow now works on something called Toybox. Any time I see Busybox used somewhere I become wary and scared.
{/opinion}


quote:
EDIT: I see what they're doing! Creating the most survivable, smallest footprint, of recovery tools.
More or less, you got it. I wouldn't use the word "survivable" though -- it's just about saving space in environments where space is not as freely available as, say, a 250GB hard disk.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.


Bill_MI
Bill In Michigan
Premium,MVM
join:2001-01-03
Royal Oak, MI
kudos:2
Reviews:
·WOW Internet and..
I'm no developer but played in the OpenWrt build environment and busybox was a constant chatter of discussion. I ran into differences with sed that made me not attempt some cable/dsl modem parameter logging on OpenWrt. I still run my build of Whiterussian 0.9 on my main router, the blazing fast and modern WRT54G v4 using the 2.4 kernel and Broadcom binary blobs.