[BusyBox] Re: [PATCH] eject umount patch n° 3 - final ( I hope)
Rob Landley
rob at landley.net
Sun May 15 00:30:14 UTC 2005
On Saturday 14 May 2005 08:13 am, Tito wrote:
> Hi Rob, hi to the list
>
> This patch fixes all remaining issues in eject
Now _that_ is optimism.
> 1) fix for the breakage of -t by last patch;
Did I? Sigh. (I couldn't test that because -t doesn't do anything on my
laptop anyway. When the tray ejects there's a catch that gets released and
then the tray pops out on a spring. Pushing it back in until it clicks has
to be done by hand...)
> 2) remove the system() call and all problems related (security, paths with
> ' or \ chars); 3) removes some unneeded #defines i put in.
> 4) removes some unneeded #includes.
>
> The size is almost the same:
> root at localhost:/dev/pts/4:/root/Desktop/busybox# size miscutils/eject.o
> text data bss dec hex filename
> 172 0 0 172 ac miscutils/eject.o.orig
> text data bss dec hex filename
> 175 0 0 175 af miscutils/eject.o.new
We'll live. :)
> Functionality should now be ok in all cases (I hope....).
+ bb_perror_msg("Can't umount");
+#ifdef CONFIG_FEATURE_MTAB_SUPPORT
+ else
+ erase_mtab(m->mnt_fsname);
+#endif
+ }
Adding _more_ mtab configs #ifdefs is kind of evil. Reading mtab is ok
because we have the /proc file, but it should really be that the prototype in
the header file and the code in the make file that get #ifdefed to a NOP if
we don't have mtab write support, rather than #ifdefing every usage of it...
Bigger change than you had in mind just now, I know. I'll deal with it as
part of my mount rewrite. I got comment about the bb_perrror_msg should die,
and I'll get it here...
In the mean time: applied.
> PS.: I would say that after the long stay in development passing to
> feature freeze for 1.1 now is a little bit early, we are just
> warming up......
I don't want a long freeze either. I just want to ship something. I think
ideally we'd want something like four releases a year, and we're already late
on that.
Maybe an intermediate release ala -pre1 instead? (Erik?)
> BTW & PPS: There is a size optimization patch for strings.c in BTS that was
> well tested and that could go in 1.1. If you have some time left could you
> take a look at it.
What's BTS?
Rob
More information about the busybox
mailing list