On Sunday 24 October 2010 02:27, Rob Landley wrote:
> I need the ability to umount everything under a given directory (so I can do
> an rm -rf even after doing a lot of bind mounting and such in a chroot), and
> the obvious thing to do is make "umount -a" use its first argument (if any)
> as
> the prefix to umount everything under. Since I wrote the busybox umount -a
> implementation as of a few years ago, it didn't seem hard to do.
>
> Except there's all sorts of... STUFF in there. For example, this is in
> umount.c. It does not belong in umount.c
>
> #if defined(__dietlibc__)
> /* 16.12.2006, Sampo Kellomaki ([email protected])
> * dietlibc-0.30 does not have implementation of getmntent_r() */
> static struct mntent *getmntent_r(FILE* stream, struct mntent* result,
> char* buffer UNUSED_PARAM, int bufsize UNUSED_PARAM)
> {
> struct mntent* ment = getmntent(stream);
> return memcpy(result, ment, sizeof(*ment));
> }
> #endif
>
> Last I checked dietlibc was too broken for words, and the _correct_ response
> to the complaint would have been "sounds like dietlibc should add that
> function then", but in any case that should be an inline living in
> platform.h.
> Dietlibc isn't umount.c's problem.
It isn't in platform.h because it needs #include <mntent.h>,
and I do not want to do that in platform.h - 99% of platform.h
users do not need that stuff.
Maybe we need to create bb_mount.h?
> There's an also #ifndef PATH_MAX which clearly belongs in platform.h, before
> I
> even _get_ to the main function. (Which is two lines of heavily annotated
> crap to start the function, but that's a separate rant.)
Hmm, you spotted a buglet. umount *abuses* PATH_MAX for a mostly
unrelated purpose: a buffer size for getmntent_r.
I'd simply use a "big enough" 4k buffer, and drop PATH_MAX from umount.c
(Did it in git just now)
> So I go look at platform.h, which has this:
>
> #if defined(__GNU_LIBRARY__) && __GNU_LIBRARY__ < 5 && \
> !defined(__dietlibc__) && \
> !defined(_NEWLIB_VERSION) && \
> !(defined __digital__ && defined __unix__)
> # error "Sorry, this libc version is not supported :("
> #endif
>
> What the...? That's not even a #warning, that's an #error. You added added
> extra complexity to REFUSE to work in an unknown environment, when specific
> apps might otherwise work. What's the POINT of programming ot things like
> SUSv4 if you don't really mean it?
>
> Good grief, you're not even checking for uClibc but just assuming that it
> will
> sufficiently pretend to be glibc. You're not only perpetuating other
> people's
> mistakes, you're trying to top them: uClibc must pretend to be glibc because
> of all the packages out there that specifically CHECK for glibc, which is
> because THOSE PACKAGES ARE BROKEN. You'd think you'd know better, that "all
> the world's glibc" is wrong, so instead of trying to be environment
> _agnostic_
> you play whack-a-mole with the historical record. Because nobody's ever
> going
> to come up with anything new without notifying you first.
Fair enough. I removed that block.
> By the way, if you're going to have the insane complextiy of "smallint"
> (apparently busybox is no longer about being simple), then where's your
> developer guide documenting it? "grep -r smallint docs" returns nothing, and
> the word does not appear in the FAQ either. New developers have to just hack
> on the code long enough to learn this by osmosis?
Added docs/smallint.txt
> Is it some sort of project senility? The older a project gets, the more
> layers of arterial plaque it accumulates until finally it's ossifies into an
> unmodifiable statue? (xmms anyone?)
>
> I spent my time on this project _removing_ as much code as I added. I
> rewrote
> existing apps multiple times because I could make them _simpler_. Is that
> still even a project goal?
Yes (as long as it works compatibly with standard tools).
> Is all this overgrowth an oversight, or do you
> guys honestly not _care_ about this stuff anymore?
I wanted to post a very similar rant about uclibc. But did not. Ranting usually
doesn't help. Doing something about things you want to see improved is the way
forward.
You are good at simplifying stuff by rewriting stuff. Thinking positively
about it, bbox is a huge field of work where you can take a small, isolated
chunk of code and rewrite it. Most other projects do not have such structure,
they are more monolithic.
*And* you have write access to git. You do not need to wait for asshole
maintainer to wake up and reply to your patches.
IOW: bbox is a nearly ideal project for you to participate, do
what you like to do, and enjoy the process.
So why are you so grumpy? :D
> When did simplicity stop being a goal?
It did not. For example, sha1/256/512 and md5 hashes were recently simplified.
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
