[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