irclog2html for #uclibc on 20060616

00:18.07*** join/#uclibc prpplague (n=dave@69.73.210.65)
01:47.33daliashmm
01:48.38daliasanyone have a good idea for an efficient way to make functions that can read from either char * or wchar_t * string without the overhead of major conditionals or function calls?
01:51.25pizza_always use one or the other
01:51.36pizza_what is the particular case you have in mind
01:52.17daliasimplementing printf, strtol, etc. efficiently
01:52.33daliassince c stupidly added wide versions of them
01:53.13pizza_yeah, wprintf already exists...
01:53.22pizza_although i thought there was a %S in printf...
01:53.29dalias%ls
01:53.34daliasbut that's not what i'm talking about
01:54.04daliasi'm talking about making one implementation of the format-string-processing core that supports both normal and wide functions
01:54.25pizza_i see
01:54.44pizza_i suppose you convert everything to wchar_t
01:54.49daliasnot an option
01:54.59daliasthe format string could be 2 gigs long
01:55.07daliasno memory for conversion
01:55.24pizza_so convert it piece by piece
01:55.38daliasthats horribly ugly and results in huge bloated code
01:56.03pizza_not necessarily, but then i'm just offering suggestions
01:56.15daliashmm i have an idea
01:56.23daliasinitialize two pointers to process the format string
01:56.27daliasone char *, one wchar_t *
01:56.55daliaspoint one at a dummy zero-initialized variable, the other at the actual format string
01:57.04daliasthen read from both and or the results together
01:57.45daliasadditional code size is minimized, as well as impact on performance
01:58.26daliasactually very little of the string is actually format specifiers that need to be processed
01:58.39daliasmost of it is just literal text that can be skipped over quickly
01:58.53daliashowever this technique could be useful for strto* family too
01:59.03daliaswhere keeping performance up is desirable
03:20.05mjn3dalias, the compromise i made was to have one function process just char * format specifiers and to convert the w* format specifiers to char.  that assumes direct translation is possible and that the format specifiers themselves don't get too long
03:27.07CIA-903vapier * r15402 10uClibc/libc/sysdeps/linux/common/getcwd.c: sync change from glibc for larger path max
03:37.21*** join/#uclibc gandhijee (n=gandhije@c-24-147-213-182.hsd1.ma.comcast.net)
03:38.58*** join/#uclibc gandhijee (n=gandhije@c-24-147-213-182.hsd1.ma.comcast.net)
04:25.23CIA-903landley * r15403 10busybox/util-linux/ (freeramdisk.c fsck_minix.c mkfs_minix.c mkswap.c):
04:25.23CIA-9Remove warnings caused by #include <sys/mount.h> in platform.h. Apparently
04:25.23CIA-9we redefine a lot of stuff from standard header files...
06:34.46*** join/#uclibc blindvt__ (n=bf@M1016P003.adsl.highway.telekom.at)
06:36.11*** join/#uclibc gcl (n=gcl@S0106001346b91f0f.cg.shawcable.net)
09:07.08*** join/#uclibc Mangey (n=mike@218.208.218.194)
09:56.37*** join/#uclibc psaksa (n=pate@ip212-226-134-137.adsl.kpnqwest.fi)
12:28.41CIA-903aldot * r15404 10busybox/networking/libiproute/ip_common.h: - add needed includes and include busybox.h needed for the ATTRIBUTE define.
12:33.25*** join/#uclibc prpplague (n=billybob@72.22.134.23)
12:45.31CIA-903aldot * r15405 10busybox/patches/cross-reference.synopsis.diff: - add patch to provide a target 'html' to build a cross-reference of the source
13:34.21*** join/#uclibc ambroseL (n=bjb@router.fidus.ca)
13:36.07blindvt__bah. booooring
13:36.41blindvt__now whoms bright idea was it to freeze busybox
13:38.37blindvt__we clearly need a "busy" branch we can hack on even if trunk is in preparation of a release ;P
14:03.25CIA-903aldot * r15406 10busybox/Config.in:
14:03.26CIA-9- hide CONFIG_GETOPT_LONG for the 1.2.0 release. Turned on per default.
14:03.26CIA-9<PROTECTED>
14:15.42*** join/#uclibc vodz (i=1000@dzo.simtreas.ru)
14:16.30blindvt__hi
16:21.19*** join/#uclibc ibot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt)
16:21.19*** topic/#uclibc is discussion of uClibc and Busybox | uClibc 0.9.28 released 17 August 2005 | busybox 1.1.3 released 17 May 2006 | for non uClibc/busybox such as buildroot and general setup issues try #elinux or #edev
16:21.49blindvtlandley, i disable the choice to toggle CONFIG_GETOPT_LONG for the release (i suppose you already saw that). JFYI
16:23.56landleyActually I haven't looked at most of today's checkins.  I just noticed the new file added when I checked to see if I could "svn update" last night's snapshot when I downloaded it to the new x86-64 machine.
16:24.22landley(I suspected it was an updateable anonymous checkout, but had never actually confirmed it.)
16:24.44landleyP.S.  I suspect I actually miss Erik as busybox maintainer more than you do.
16:25.00landleyI would MUCH rather be off working on bbsh than tracking down warnings in code I've never even touched before...
16:25.24landleyI really don't _like_ having this kind of argument.
16:25.46landleyI also don't like having new things I'm responsible for (if they break) thrust on me without even warning, let alone asking.
16:26.06landleyI haven't got hardware to test this one out on.
16:26.14landleyI haven't even got an emulation environment to test it on.
16:26.44landleyI don't actually know anybody who _does_.  (I used to have ssh access to an SMP machine, but it was replaced by an x86-64 box that was faster than all 4 of the old processors put together.)
16:26.59landleyI could ask around timesys, I suppose...
16:27.06blindvtlandley, already commented on that proposed "debloat lash" patchlet i sent to the list earlier today?
16:27.33landleyI asked.  The boggled slightly and reminded me we're an embedded company...
16:27.33blindvtlandley, please do if you find the time. It really is up to you to decide. TIA
16:28.02landleyblindvt: I have it open on my desktop.  The first 1/5 of it or so looks reasonable.  (I deleted the debug_printf, which only had one instance, rather than try to fix it up.)
16:28.24landleyHaven't had a chance to make it through the rest.  Today is a non-busybox stuff day.
16:28.24landleySaturday and Sunday, I get to work on busybox some more.
16:28.37landley(I'm skipping the Penguicon concom meeting to stay home and do this instead.)
16:28.45landleySpeaking of non-busybox stuff...
16:28.46blindvtlandley, ough. that's bad. Well hopefully this eavening or this weekend
16:28.52landleyI need to go do that.
16:29.08vodzplease revert http://www.busybox.net/cgi-bin/viewcvs.cgi/*checkout*/trunk/busybox/libbb/vfork_daemon_rexec.c?content-type=text%2Fplain&rev=15333
16:29.35landleyI was a bit conflicted about my first lash debloat patch  because it makes lash an even harder target for bbsh to replace.
16:29.37blindvtlandley, do so, but stay here to be able to read at least the stuff one may be inclined to check with you, will you?
16:29.52landleyBut the best thing for busybox as a whole is to fix everything fixable of the code that's already in, so...
16:29.55blindvtlandley, i'll keep it low, promised.
16:30.00landleySure.
16:30.02landley15333?
16:30.39vodzyes . vfork_daemon() is not usable. - vfork() wait child always. Must restore vfork_rexec
16:30.41landleyYeah, that does look kinda broken, doesn't it?
16:30.52blindvthttp://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/libbb/vfork_daemon_rexec.c?rev=15333&view=diff&r1=15333&r2=15332&p1=trunk/busybox/libbb/vfork_daemon_rexec.c&p2=/trunk/busybox/libbb/vfork_daemon_rexec.c
16:30.55blindvtfor the diff..
16:31.24landleyvi patchlist/svn-15333.patch in my case. :)
16:31.32landley(That's why I made the download/patches directory in the first place...)
16:31.48landleyWhat was mike trying to do, I wonder?
16:32.07blindvtthat whole bb_xdaemon eventually wants argc and argv exported globally and wants 3 args, evaluated depending on BB_NOMMU. At least from my POV
16:32.08landleyNothing about it on the mailing list...
16:32.18landleyblindvt: agreed.
16:32.32blindvtlandley, there. Bitch at vapier, not /me :P
16:32.36landleyI was planning on trying to merge vfork_daemon_rexec() and bb_spawn() at some point in the future...
16:32.45vodzi unsubscibed bbmailist
16:32.45landleyOh, I'm just going to revert it, as vodz asked.
16:32.48landley(Strange but true.)
16:33.02landleyvodz: there's a web interface if you care to check in occasionally. :)
16:33.38vodzlandley: yes. But if have very big fun only now
16:34.01landleyDidn't quite understand that translation...
16:34.20landley"only if you really want to", perhaps?
16:34.20blindvtlandley, so, i'm curious about the kind of freeze we're currently in.
16:35.09blindvtlandley, i have reordered getty.c so it's actually readable, without debloating it yet. Is that something you accept to be applied to trunk now or not?
16:35.27landleyblindvt: is the resulting binary the same?
16:35.31blindvtlandley, if not then i will create me a branch to hold my work in progress stuff
16:35.40blindvtlandley, bit-wise, yes
16:35.50vodzall wtmp/utmp stuff in busybox is broken: busybox init unsupport utmp/wtmp stuff
16:35.56CIA-903landley * r15408 10busybox/libbb/vfork_daemon_rexec.c:
16:35.56CIA-9Revert svn 15333. If you vfork, you must either exec or exit. (The parent is
16:35.56CIA-9blocked until you do so.)
16:36.03landleyblindvt: then go ahead and check it in.
16:36.04blindvtlandley, likewise with the "debloat lash" stuff.
16:36.36landleyCode refactoring can still go in if the resulting binary doesn't change.
16:37.09CIA-903aldot * r15409 10busybox/loginutils/getty.c:
16:37.09CIA-9- do away with the fwd-decls of functions. Should not contain any code changes
16:37.09CIA-9<PROTECTED>
16:37.10landleyI just want to catch up with the already submitted backlog (or some subset thereof), and then have about a week of "ok, test this please" with bugfixes only, before releasing.
16:37.52blindvtlandley, don't forget that lash thing..
16:37.57landleyAnd since it's already halfway through the month and I promised a release out in June... :)
16:37.58blindvtbbl
16:37.59landleyblindvt: I won't.
16:38.00vodzblindvt: fwd-decl is "debloated" ?
16:38.15landleyvodz: he's talking about making the source more readable.
16:38.22blindvtvodz, it makes the code merely unreadable
16:38.26landleyDebloating the source, not the compiled code.
16:38.54landleyI gotta go do other things now...
16:39.00blindvtvodz, the debloat was lash (see ML, and comment, if you feel like!)
16:39.06landleyI'll leave the chat window open, but am only likely to check in every hour or two...
16:39.19blindvtlandley, cool
16:39.24landleyErik made the mailing list subscriber-only because he was overwhelmed with spam.
16:39.47landleyI haven't changed that because I can't moderate that much spam either...
16:39.52blindvtvodz, i'd be interrested to have your comments on it. Do you see it or do you prefer an URL?
16:40.57landleyPossibly I could set up some kind of busybox-moderate@busybox address that people (other than me) could check and pass through?
16:41.07landleyFor non-subscribers to post to?
16:41.14vodzblindvt: i do not unsubscibed svn-log-mailist
16:41.35landleyI never subscribed to the svn log list, but I check each commit by hand, so... :)
16:41.56landleyOk, _now_ I go do other work...
16:45.59vodzdebloated debloated... heh. new platform.h do more and more bloat
16:47.21vodzendian, networking, sys/mount.h O may god
16:49.24daliasyes
16:49.36blindvtvodz, yes. Especially broken is that the guard for the attributes were removed. I'm absolutely sure that there will be bug-reports about the missing guards in 1 or two years. *shrug*. I did make it properly, it was broken by someone else. It's a pity, but i guess i have to live with that for now
16:49.57*** join/#uclibc andersee (n=andersee@codepoet.org)
16:50.44blindvtvodz, i don't care. Someone else broke it on purpose, so that entity will have to figure it out.
16:50.51blindvtandersee, rehi
16:51.00daliasvodz left
16:51.09anderseeblindvt: morning
16:51.49blindvtdalias, yea. Good as did good taste by removing harmless guards.
16:51.56blindvtdalias, so? ;)
17:00.13landleyMorning andersee.
17:02.35landleyblindvt: If a header starts doing "#define ATTRIBUTE_UNUSED 3" you're saying this won't cause a problem?
17:19.42CIA-903aldot * r15410 10busybox/Makefile:
17:19.42CIA-9- add cross-reference generation target.
17:19.42CIA-9<PROTECTED>
17:28.37blindvtlandley, you are pessimizing commercial compilers by that, nothing more, nothing less.
17:29.27blindvtlandley, i know that YOU don't care about those, but i happen to to try to make sure that busybox is useable as opposed to gcc-compilable.
17:29.54blindvtlandley, i have reverted that change in my local repo, FWIW.
17:31.40*** join/#uclibc Sgt-Donan (n=Loutre@feu30-1-82-242-59-35.fbx.proxad.net)
17:36.30landleyI agree that I don't care about that.
17:39.10blindvtyea it's a pity
17:40.57blindvti guess all is well as long as it compiles with gcc-3.x on i386 linux
17:41.15blindvtsee e.g. your recent lash changes :-(
17:41.26blindvtanyway.
17:42.21blindvti'm merely an innocent bystander in this respect. Busybox your baby by now
17:43.42landleyNope, ARM, PPC, MIPS, and x86-64 Linux are all important too. :)
17:43.47landleyAs is gcc-4.x
17:44.26prpplaguelandley: hey, how dare you put ARM and MIPS in the same sentence! hehe
17:44.53landleyThey've apparently got them on the same rack here at timesys.
17:45.03prpplaguelandley: shame shame
17:45.05landleyAlong with something called Super H, but I have yet to start caring about that one.
17:45.20prpplaguelandley: thats like letting your food touch on the cafeteria plate
17:45.21blindvtSF's compile farm is up again, so there are plenty of linux-flavours as well as BSD flavours one can test busybox with, before triping bugs in the release tarball. Not sure if andersee did that, but i'd certainly at least try to see where it will brk
17:45.46landleyWhere is sourceforge's compile farm?
17:47.16blindvtcf.sf.net
17:48.01landleyGoogle found http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1
17:48.07landleyWhich I can only hope is out of date...
17:48.56blindvti once started to peruse them and andersee did apply most of the fixes stemming from there. Too bad that the habbit of providing a working set appears to have changes :-/
17:49.10landley(Fedora Core 2 and Debian 3 on x86, two Opterons both running FC3, and a PPC running SLES 9.)
17:49.31landleyI think I can scrape up that much locally.
17:49.54blindvtlandley, even if i suppose fixes to take over the BSD world with GPL source, i hear from you that this is non-standard and that you plain dislike them. Very discouraging :(
17:50.16landleyWith BSD it's really just a lack of caring.
17:50.20landleyThey're irrelevant and always will be.
17:50.33landleyEvery time they get any kind of market share, their developers are hired away by a proprietary fork.  Most recently MacOS X.
17:50.44landleyMacOS is interesting, though.
17:50.59landley(Before MacOS X there was BSDi.)
17:51.07landley(Way back in 1982, Bill Joy was hired away by Sun.)
17:51.13blindvtthat's not an attitude that can possibly serve as a base for anything, right.
17:51.20landley*shrug*
17:51.27blindvtgrats.
17:54.46blindvtso we don't want to run on MACosx even if it was easy to do so, due to politics emposed by the maintainer. Brilliant idea
17:55.04landleySo you missed the MacOS is interesting though, above?
17:55.16landleyOr my repeated statements taht I find MacOS X interesting?
17:55.26blindvtlandley, you don't act like it.
17:55.26landley(Heck, I bother to capitalize it correctly, which I don't bother to do for most things.)
17:55.36landley*shrug*
17:56.04landleyIt's not a priority for me.
17:56.05blindvtlandley, you remove harmless guards and just *shrug*.
17:56.11landleyIf it is indeed easy to do...
17:56.25landleyblindvt: if somebody redefines something that we define, how do you know they #define it to the same thing?
17:56.33landleyConsidering that they haven't even _done_ it yet, you can't.
17:56.47blindvtlandley, it also is no priority for me, but i like to be able to support them, not forcefully knocking me out of that kind of affairs.
17:57.01landleyIf you build it in an environment that we haven't tested it in yet, it may break.  The guards don't change that, so they serve no purpose whatosoever.
17:57.07landleyThey're guards around a name WE MADE UP.
17:58.00blindvti'm not interrested in discussing it. If your official politics is that we only care about 32bit linux, so be it with that source.
17:58.05landleyYou want to add a bb_ prefix in front of every busybox function in case of name collisions with an unknown environment.
17:58.14blindvtit's wrong
17:58.22landleyI don't care about supporting an unknown environment.  I care about supporting a finite number of known environments.
17:58.36landleyIt's always possible to port to other environments, but that's porting.
17:59.20blindvtlandley, andersee did. Do stop suggesting that *I* started this. That assumption is freaking wrong and utterly stupid. It's a matter of usability, nothing more. You don't like it? fine. ditch it. Still it's wrong to ditch it.
17:59.23landleyblindvt: I'm in the process of fixing up the x86-64 warnings (as I told you this morning), so once again you're ignoring recent evidence to go off on a snit.
18:00.07landleyCriticizing my position I'm fine with.  Criticizing a straw man makes me stop listening to you.
18:00.16landleySpeaking of which, back to work...
18:01.00blindvtif one strives to be spoiled in GNUism, so be it, even if it's a pity.
18:01.21landleyNope, wanna work with uClinux too.
18:01.58landleyWorking on busybox (and testing against uClinux) in an attempt to get a Linux without any gnu stuff on it.
18:02.06landleyExcuse, uClibc.
18:02.12landley(Two conversations at once...)
18:04.52dalias:)
18:05.31landleyIf I had a copy of MacOS X I could run under qemu, I'd have poked at it a lot more by now.
18:05.39landleyRight now when a MacOS patch comes in, I can't test it.
18:05.50landleyI don't even have the documentation for this.
18:06.09landleySo mostly I try to make sure it doesn't interfere with the rest of busybox, and inconvenience the existing Linux users.
18:06.54landleyI suppose I could poke at that debian Darwin thing, but I dunno what relationship that has with the real MacOS X...
18:07.03landleyThat's waaaaaay down on the todo list.
18:07.08landleyRight down there with flossing the cat.
18:08.45blindvtlandley, you don't do that on a regular basis? :P
18:09.04blindvtlandley, but can you at least see my motivation?
18:09.58blindvtlandley, i try to broaden the scope of busybox as an alternative for the basic function a distro (be it GNU/Linux or BSD-*) uses.
18:10.19landleySome of this e2fsck code is just _insane_.
18:10.31landleyFound %llu bad blocks starting at block number: %u
18:10.40landleySo the length is 64 bit, but the starting point is 32 bit.
18:10.43landleyHow does that work?
18:11.00landleyblindvt: I see your motivation.
18:11.04blindvtlandley, that way, we _can_ make GNU stuff more widespread used, which is a good thing, imo
18:11.11landleyPart of it is I want to get the functionality right on Linux before worrying about other platforms.
18:11.28landleyPart of it is I want to expand in a controlled fashion, which involves refactoring existing stuff rather than gluing new bits on haphazardly.
18:11.48blindvtlandley, let's screw them, if their users want GNU, small, efficient, they will cry for it and in the end they will get it.
18:12.05landleyPart of it is that I hate being responsible for things I cant test, so I want to know who _will_ be responsible for that.  I mean years from now.
18:12.21landleywhose users?
18:13.14landleyAndersee wandered away after 1.00 in part because he didn't think busybox needed more stuff added to it.
18:13.28landley(Feel free to jump in if I'm mischaracterizing here.  I know you had a half-dozen different motivations...)
18:13.44blindvtlandley, E.g OpenBSD users, NetBSD users, FreeBSD users, APPLE-OS users, you name it. I want to be there, and we could with only a very little effort -- at least with less counter-effort from e.g. your part.
18:13.45landleyThe 1.00 release was "good enough".
18:14.16landleyThe trap of a "does everything" tool is that if you're not careful, it can turn into emacs.
18:14.21landleyI'm trying to avoid that.
18:14.27prpplagueamen
18:14.32blindvtlandley, first and as a clear emphasis, we want embedded linux small, granted.
18:14.53landleyIt's hard for one developer team to be an expert in dozens of different areas.
18:14.57landleyWe are not the world's experts on SMP.
18:14.58blindvtlandley, second is the same for linux-desktop, 100% agree
18:15.06landleyAdding smp tools requires us to learn new stuff.
18:15.19landleyAnd once simple SMP tools are in, they'll be used as an excuse to add more complicated SMP tools.
18:15.32prpplagueor raid
18:15.35blindvtlandley, desktop and servers by now also mean SMP, that's just reality, nothing more, nothing less.
18:15.48landleyShow me an SMP laptop.
18:16.05landleyLaptops outsell desktop hardware in both unit volume and revenue.
18:16.40landleyhttp://www.usatoday.com/tech/news/2005-06-06-laptops-outsell_x.htm
18:16.51landley2005 was when the _second_ of those metrics was passed.
18:16.54blindvtprpplague, don't be silly. RAID, from a user-perspective is purely kernel, and if they want LVM, they have to stick with the external big stuff, just like they should with minix/ext2/ext3 FS generation, from my POV
18:17.20landleyDo we have a battery monitor?  No.
18:17.25blindvtlandley, sure
18:17.27landleyBut we're growing SMP functionality.
18:17.35landleyThe priorities here are something I question.
18:18.13blindvtlandley, <CAPS> SURE WE HAVE A FREAKING BATTERY CHECKER!
18:18.23landleyblindvt: where?
18:18.26landleycat?
18:18.28blindvtjust look at that darn e2fsprogs!!!!
18:18.35prpplagueblindvt: there are plenty of raid tools that could be argued for
18:18.50landleye2fsprogs could hide an elephant in that overgrowth.
18:19.01landleyAs I mentioned, I didn't add it.  I wouldn't have added it.
18:19.14blindvtprpplague, no. Just like e2fsprogs they have nothing todo in busybox for now and for the foreseeable future point.
18:19.14landleyThat's a classic example of camel's nose under the tent flap.
18:19.33landleySomebody checked in chattr, and then followed up with 100 files of crap.
18:19.37landleychattr by itself made sense.
18:19.43landleyThe 100 files of crap emphatically did not.
18:19.45prpplagueblindvt: agreed, but all i was saying is when you open the door a little, sometimes some pushes it open more
18:21.41landleyLook at svn 10151.  Vapier imported lsattr and chattr.
18:21.43blindvtlandley, see how i'm exceptionally freaking out by you bitching at taskset and chrt? There is a multi-hundred kilobyte mess in the tree which is freaking nonsense, and you feel uncomfortable with a tool which is used in the real world and which is well under 1k in size? *That* i call invalid measure, sorry :)
18:21.55landleyAnd they desperately needed to be cleaned up.  But those two applets, by themselves, were reasonably small.
18:22.23landleyThen because those weren't immediately ripped out, the whole of e2fsprogs wound up dumped into busybox, un cleaned up, and it's still there stinking up the place.
18:22.39blindvtlandley, and by in the real world i mean frequently durnig the runtime of a system, and not during the setup of it
18:22.52landleyblindvt: the last multi-hundred kilobyte mess in the tree happend because Mike Frysinger checked in two little apps.
18:22.54blindvts/durning/during/;# even
18:22.56landleyCamel's nose under the tent flap.
18:23.02landleyDon't use existing crap as an excuse to put in more crap.
18:23.12landleyDon't say "I don't have to clean up X, look how dirty Y is".
18:23.17landleyThat's NOT AN EXCUSE.
18:23.31blindvtanyway. I'll calm down and get more important stuff done and you should do...
18:23.45blindvttoo..
18:23.46landleye2fsprogs has nothing whatsoever to do with whether or not busybox should take on the entire SMP world.
18:24.02landleyBringing it up actually _undermines_ your position, because it shows you just don't get what I'm objecting to.
18:24.18landley"Look how badly this worked out last time, why don't we do it again."
18:24.20landleyUndermines.
18:24.36landleyAh yes, other work...
18:24.47blindvtlandley, SMP is reality, even in the embedded world. As is RT. Creating ext2 filesystems is usually not, at least not in my world
18:25.12daliasi find creating ext2 fs much more practical than smp
18:25.33daliasthe former is actually needed to bootstrap a system
18:25.38daliasthe latter is purely extra
18:28.42blindvtdalias, the former (creating an FS) is usually done at target-creation time, the latter is stringently needed at target-runtime.
18:29.00daliass/needed/bonus/
18:29.02blindvtdalias, so i beg to differ as it's exactly the other way 'round :)
18:29.17landleyblindvt: I could see us not doing _either_.
18:29.21daliasno userspace tools whatsoever are _needed_ for an smp system, the smp is not even needed
18:29.29daliasthe system will work if you leave all but one cpu idle :)
18:29.37landleyThere's a perfectly good e2fsprogs package (ok, it sucks, but the busybox stuff sucks too and is a direct port of that).
18:29.38daliasbut the system will not work without a filesystem
18:29.47landleyAnd there are existing smp tools.
18:29.55daliasi question whether e2fsprogs is "perfectly good"
18:29.58landleyBusybox does not need the linux kernel bolted on it.
18:30.14landleyBusybox does not need to reimplement the C library.
18:30.24blindvtdalias, no. It will be slow/inappropriately setup if you don't pin maintenance-tasks to the system-cpu and leave the production CPU free for the Real Tasks
18:30.26landleyThere are things busybox does not need to do, that the rest of the system may need to do.
18:30.38landleyblindvt: this is not my problem.
18:30.44landleyThere are systems that need special device drivers.
18:30.55landleyWhatever your realtime task is, that's userspace code, right?
18:31.07landleyWE'RE NOT BOLTING THAT BESPOKE REALTIME TASK INTO BUSYBOX.
18:31.21landleyYou are welcome to do so in your own copy.
18:31.36landleyBut it's not going in the vanilla version.
18:31.53blindvtdalias, do you know anybody except desktop that actually uses e2fsprogs? I don't. Embedded usually uses anything but ext2/3, from what i've seen
18:32.06daliasblindvt, bb is not embedded-only
18:32.22daliasit's the only viable set of core posix tools for a workstation/server
18:32.27landleyblindvt: e2fsprogs being bad, and possibly needing to be removed, is not a defense of adding additonal unrelated crap.
18:32.27daliasdue to gnu ones being hopelessly broken
18:32.30daliasand bloated
18:32.34landleyyes, SMP hardware exists.
18:32.35landleySo does RAID.
18:32.41landleySo does xvidtune.
18:32.48landleyWe're not bolting the X server onto busybox.
18:32.51landleyEither.
18:32.59prpplagueblindvt: there are several thin client apps that use ext2, including some ltsp stuff
18:33.12blindvtdalias, well, also servers and desktop, yes. Desktop as well as servers nowadays are SMP (at least CPUs with HT), so how's taskset bad? :)
18:33.32landleyI don't have an SMP desktop.
18:33.36landleyI don't know anybody who has an SMP desktop.
18:33.45daliasblindvt, i didnt say it was bad. i just said it's nonessential to a working system
18:33.49daliasbut yes landley is right
18:33.52landleyI used to know people who had SMP desktops, but they replaced them with newer single processor machines that were faster than the SMP system.
18:33.53daliassmp desktop is idiotic
18:33.58daliashuge waste of electricity
18:34.22landleyThe huge noisy power supply that kept filling up with dust was an issue, yes.
18:34.29prpplagueblindvt: sorry but i agree with landley
18:34.33landley(Not the electric bill, or the heat.  The _noise_.)
18:34.38blindvtdalias, also, some percentage of embedded are SMP, and these need taskset *and* chrt. Currently, they all use the external applets, which are all about 10x the size of what we currently have, fwiw.
18:34.56landleySome precentage of the embedded systems out there run OS9 or QNX.
18:35.00landleyMy lack of caring is deep and profound.
18:35.06daliasblindvt, i'm not against including more tools in bb as long as they're optional and don't bloat bb for ppl who disable them
18:35.27landleyI don't want another e2fsprogs.
18:35.40landleyI don't want people using "oh, you support SMP now?  Well here's this huge pile of code" as an excuse again.
18:35.50landleyI just don't want to go there.
18:36.08daliasjust reject code that's bloated
18:36.19daliasthat will keep the idiots away
18:36.25landleyWe don't have iptables (when one of our biggest use cases is embedded routers), yet you want to add SMP support.
18:36.26blindvtdalias, which is exactly the case for tasket (about 520 Bytes) and chrt (about 1kByte). You don't want them? Leave them disabled
18:36.27landleyAnd you didn't even ask.
18:36.40landleyThe didn't even ask is the part that I'm still kind of annoyed about.
18:37.06daliasiptables would be nice to have in bb
18:37.14daliassince the standalong iptables is massively bloated
18:37.22daliasand full of dynamic-loaded library nonsense
18:37.30landleyYeah, it's a todo item.
18:37.33landleyI have a bucket full.
18:37.38daliasyeah :(
18:37.44landleyAdding SMP crap was not in the todo list.
18:37.48dalias:)
18:38.02blindvtlandley, yeah, i should have send it to the list first, i agree, and i somehow felt dirty about checking it in even back than. Thanks for beating me even more now ... :(
18:38.33landleyWe can add a "big and tall menu".
18:38.45landleyI want to get the infrastructure right before adding the functionality.
18:38.54landleyI don't care if _this_ applet is 500 bytes.
18:39.03landleySee "camel's nose" and "tent flap", earlier.
18:39.12landleyBut I _really_ need to go work on other things right now... :)
18:39.23blindvtlandley, still, a) it's small b) configurable c) without dependencies d) optional e) nice f) good g) not big h) hmz.. ;)
18:39.29blindvtlandley, k.
18:39.40landley"Wafer thin mint?"
18:40.03landley(Excuse, "Wafair thin mint?"
18:40.43blindvtlandley, i'm not a native speaker, so fogrive me to break my silence and ask what that is ment to mean?
18:41.00landleyIt's a line from Monty Python's "The Meaning of Life".
18:41.06landleyThe Mr. Creosote sketch.
18:41.07blindvtgrief! s/fogrive/forgive/
18:41.09blindvt;)
18:41.38landleyAs with all Monty Python, if you haven't seen it no amount of explaining is going to help.
18:41.55blindvtno idea. landley i'll just pass and let you work.
18:42.27daliashey
18:43.13daliasif i make a patch for ls to do column widths correctly (wcwidth rather than strlen) and make it optional, will that be accepted?
18:47.51landleyI believe LS already has locale support #ifdefs in it.
18:47.56landleyIs wcwidth() a locale thing?
18:48.36daliasi rtfs'd and the necessary support is not there
18:48.44daliasit just uses strlen to determine width in columns
18:48.55landleyWhat is wcwidth?
18:49.01landleyIs it part of locale support?
18:49.04daliasyes
18:49.09daliaswcwidth() tells the 'printing width' of a character
18:49.17landleyIn that case, just put it under the existing LOCALE config item.
18:49.23dalias0 (for combining characters), 1 (normal), or 2 (east asian wide)
18:49.26landley(Add it, but make disabling that config it out.)
18:49.33daliasok
18:49.52landleyCONFIG_LOCALE_SUPPORT in the top level Config.in.
18:49.57daliasyeah
18:50.06daliaswait
18:50.17daliasdo you mean to put another subconfig item under CONFIG_LOCALE_SUPPORT?
18:50.22landleyIn fact we should probably put all the utf8 stuff under that...
18:50.24daliasor just make this feature depend directly on CONFIG_LOCALE_SUPPORT?
18:50.28landleyNo, the existing one's fine.
18:50.34landleyIf they want locale support they probably want it everywhere.
18:50.37daliasok
18:50.44landleyThey've already sucked in the library stuff for it, might as well use it at that point.
19:03.02blindvtlandley, later... opposed to me changing the chdir("/") in vfork_daemon_common() do xchdir?
19:03.18landleyNope.
19:03.26landleyBut if chdir("/") fails, you have bigger problems. :)
19:04.21blindvtyeah, i reckon this. That's why ;)
19:10.38landley*shrug*  I'd be happy not testing at all, but xchdir works too if we've got it...
19:23.47blindvtthat xcalloc wants to be xzalloc too. If anyone has an argc that would overflaw, then they most likely still get what they deserve, i think
19:24.03blindvtmerely political question, though
19:24.47blindvtso I'm not interrested in it, which is implied from my part in these kindof(questions)
19:36.20*** join/#uclibc centyx (i=centyx@centyx.net)
19:39.52*** join/#uclibc ashes (n=ashes@modemcable085.56-130-66.mc.videotron.ca)
19:41.32*** join/#uclibc FireEgl (i=Atlantic@Atlantica.US)
19:55.53blindvthm. that xchdir will break due to calling exit instead of _exit, no? Can't test.
19:56.15blindvtlandley, do we have a nommu target available via qemu?
19:56.49blindvtit sucks badly that i have no idea about that aspect of affairs :/
20:06.34landleyblindvt: I know there's a way to do it, but I dont' know how off the top of my head.
20:07.10landleyblindvt: if xchdir("/") fails, it doesn't really matter what recovery steps it takes.  Your system is so badly hosed that power cycling is called for.
20:07.33landley"/" is a symlink built into the kernel, part of the VFS rather than any specific filesystem...
20:07.56landleyThat's why I'm ok just not testing if that fails.  It should never happen, and there's nothing we could do about it if it did.
20:08.03blindvtlandley, ok, so if we're already *so* screwed there, we just don't care, right?
20:08.10landleyBasically.
20:09.04blindvtok
20:10.09blindvtdo you think you'll find the time to skim over that lash debloat today? Just hoping/poking? :)
20:10.56blindvtlandley, i think it should be ok (running it since about a week here), but i'm uneasy if you want it in 1.2.0 or not..
20:12.22landleyblindvt: possibly this evening.
20:12.29landleyYes, it's still ok for 2.0.
20:12.47landleyI glanced at it enough that it looked reasonable.  At least some subset of it's going in, possibly the whole thing.
20:13.04landleyJust haven't finished reading it, yet, on other stuff today.
20:13.14blindvtlandley, erm. excuse me.. 2.0?
20:13.26landley(The flip side of having tuesdays and thursdays at home to do busybox is that it's not a priority MWF.)
20:13.28landley1.2.0.
20:13.35landley(Yeesh, I did Java for too many years...)
20:13.58landleyThey insisted that 1.2 was 2.0.  Then they came out with 1.3.
20:14.00landleySun can't count.
20:14.09blindvtlandley, you want to be 1.3 the -pre for 2.0, do i get this right? As 2.0 as of mid/end Jannuary, if i may suppose that?
20:14.25landleyI have no immediate plans for a busybox 2.0 right now.
20:14.31landleyI'm not even sure what the criteria would be.
20:14.46landley1.1.1 showed that not advancing the middle number when you include significant new development is confusing.
20:14.48blindvtso we're still gold with 1.x, ACK?
20:14.53landleyThe third dot is for bug fixes.
20:14.55landleyYup.
20:15.02blindvtokok.
20:15.03landley2.0 above was a typo on my part.
20:15.10landley(Well, thinko.)
20:15.19blindvtbad landley :)
20:15.23landleyMoving towards the end of the workday, eating skittles to keep the blood sugar up.
20:15.52landleyThere are _pink_ skittles now.
20:16.08landley"Taste the rainbow.  It's pink."
20:16.27blindvti took a day off to be able to finish my gcc stuff, so i'm fortunate today to have had a day off the mess 8)
20:16.48landleyWhich gcc stuff?
20:18.00blindvtwell, fixing the install failure on OSF1 and verifying linux and a couple of BSD with that fix and i finally managed to finalize that "set but not used" thingy in a reasonable manner.
20:19.21blindvtunfortunately the latter is really involving, i.e. to have the proper granularity, i have to change a couple of nasty aspects in the way CFG interacts with gimple. Still pondering how to make it less intrusive :/
20:21.02blindvttrunk is frozen for 4.2, so i have plenty of time until such a change will possibly accepted, but the C frontend is a hack, compared to the much, much nicer Fortran FE, at least IMHO.
20:21.52landleyI'd say I followed about 20% of that.
20:27.05blindvtanyway. it's working like it should, but it gives fewer warnings as it could legitimally (is that an english word? nah.) since i cannot change the inner workings of it to the degree i would need to make it behave like some commercial FE's
20:28.14blindvtwell, i can and did, but these are so intrusive that they will not go in anytime soon.
20:30.53landleyWhat's an FE?
20:31.00blindvtFrontEnd.
20:31.09landleyFortran?
20:31.53blindvtlandley, basically, i'd did implement one aspect of http://www.edg.com/ in gcc, to be able to see these.
20:32.09blindvtlandley, think coverty, intel compiler et al, if you like.
20:33.21blindvtwhatever. Guess you need to work or review that lash thingy of mine (with a discussion on-list or PM!), so don't bother :)
20:38.44landleySorry, me and a co-worker are poking at a serial port analyzer thingy.
20:38.59landleyTrying to write a dumb little minicom replacement to go into busybox at some point.
20:39.03landleyBasically netcat for a serial port.
20:39.10landleyProbably combine it with netcat...
20:39.37landleyThink I hit a kernel bug to tell you the truth.
20:39.43blindvtlandley, RIP netcat while at it! FORE!!
20:39.49blindvt:)
20:39.51landleyI vaguely remember something about this a year ago, but my desktop's using a 2.6.12 ubuntu...
20:40.09landleyblindvt: actually, I have my own implementation of netcat I wrote in 2001.
20:40.25landleyWhere'd I put that...
20:41.02blindvtlandley, if it sucks less, then schedule (sorry..) it for 1.3.0 ..
20:42.06landleyJust threw it on http://landley.net/netcat.c
20:42.25landleyVery old, kind of pathetic code.
20:42.31landleyBut it handles shutdown properly, and is small.
20:42.37landleyDoesn't do the dns lookup...
20:44.45landleyI'm pondering putting some kind of pipecat() function in libbb that does the whold poll/read/shutdown loop.
20:45.03landleybb_pollsend()?
20:45.09landleyHave to come up with a name for it.
20:45.40landleyOr I could just combine netcat and pipecat (the replacement for minicom).
20:45.45landleypipecat /dev/ttyS1
20:45.56landleyIf you want to setserial, use the setserial command.
20:46.23landleySerial consoles definitely _are_ within our mandate. :)
20:46.34landleyIf wandering towards obsolescence...
22:29.09CIA-903landley * r15411 10busybox/docs/busybox.net/ (about.html copyright.txt footer.html shame.html): Make it so Erik has to forward me less email.
22:37.40*** join/#uclibc blindvt (n=bf@M993P016.adsl.highway.telekom.at)
22:40.47*** join/#uclibc prpplague (n=dave@69.73.210.65)
23:21.23*** join/#uclibc wliad (n=wliad@85.65.199.81.dynamic.barak-online.net)
23:22.12*** part/#uclibc wliad (n=wliad@85.65.199.81.dynamic.barak-online.net)
23:45.06*** join/#uclibc FireEgl (i=Atlantic@Atlantica.US)

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net! Modified by Tim Riker to work with blootbot logs, split per channel, etc.