svn commit: trunk/busybox/libbb

[Mike Frysinger]

On Sunday 25 June 2006 11:56, Rob Landley wrote:
> On Sunday 25 June 2006 1:49 am, Mike Frysinger wrote:
> > > I'm much happier having documentation that allows a human to look up
> > > the number they need to supply when that value is so nonstandard that
> > > the source code would need an #ifdef to figure out if that value is
> > > even supplied by the standard headers or not, and which we can't _not_
> > > take from those headers because they vary so much.
> >
> > and thus break compatibility with stty used everywhere else ?  where do
> > we draw the line in terms of "this is how standard utilities work, but
> > this is how busybox works because its more convenient for us than to
> > maintain compatibility"
>
> Or if you prefer, we can simply not support the faster speeds at all.

or you provide a build option like we do with every other utility
[ ] Support all stty speeds

turned off -> support only standard/common speeds
turned on -> support all speeds

> Since you've come out so clearly in favor of not doing this at all rather
> than doing something that isn't standardized in the first place in a
> nonstandard way, I can live with that.  (And if this is "standardized"
> please tell me what spec says that any speed faster than 115k should be
> supported?

you're talking about two completely different things here

there's the standard interface as defined by the real utility (stty in this 
case) and then there's the standard speeds that hardware supports

> _Which_ faster speeds are supported?  How do you get a list?  
> Can you just guess and have it round down, or do you have to get the number
> exactly right?)

uhh, the answer is obvious ... if it's in the linux kernel sources, it's in 
stty

> And no, I don't trust your judgement on this issue since you're the one who
> checked e2fsprogs into the tree and never cleaned it up.  I recruited
> Garrett to clean some of it up a little, and have plans to rip out chunks
> of it and rewrite them (mke2fs, tune2fs) if I can ever get the time, but
> this is cleanup work you dumped on me.  You are obviously not bothered by
> bloat.  I am.

i could really care less about your views on things ... oh no, Rob Landley 
doesnt trust my judgment ?  end of the world !

go back and read the threads where i said "this code sucks so i'll only merge 
it if other people feel like helping out clean it up as i dont have time to 
it all properly".  other people responded in the affirmative, and since there 
was and is plenty of demand for these utilities, i merged it ... then people 
started sending patches to clean it all up.  funny how open source community 
projects work like that.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20060625/a8e25f96/attachment.pgp