Re: [BusyBox] Re: [PATCH] eject umount patch n° 3 - final ( I hope)

Jason Schoon floydpink at gmail.com
Mon May 16 00:05:17 UTC 2005


I'm guessing he is referring to the bugzilla database (BTS == Bug Tracking 
System).

On 5/14/05, Rob Landley <rob at landley.net> wrote:
> 
> 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
> _______________________________________________
> busybox mailing list
> busybox at mail.busybox.net
> http://busybox.net/mailman/listinfo/busybox
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20050515/fd43f397/attachment-0001.htm 


More information about the busybox mailing list