Re: Proc fs limit workaround?
Ricky Beam wrote: > > On Thu, 14 Sep 2000, Nick Pollitt wrote: > ... > >And second, why is the 4K limit there in the first place? > > Primarily because it was never designed for 90% of the crap that's in there > now. I have long hated the BS required to get more than 4k worth of stuff > out of /proc. The way around the limit is not a solution, it's a hack. > There's not atomicy for processing more than one page unless you go out > of your way to deal with it. I've banged my head on the desk a few times > because of this -- what happens when there's any delay between read()'s? > *sigh* > > #ifdef RANT > In case you haven't noticed a lot of present-day linux is a nice collection > of hacks. This is the nature of code evilution -- I have to deal with this > everyday (of course, I'm paid to.) procfs was actually a Very Good Thing(r) > six or seven years ago when it was _designed_. Now look at it. > > I'm a perfectionist. I like things to be well planned, designed, and > emplimented to do what they were designed to do. If you want it to do > something else, return to the planning stage. For example, 747's weren't > designed to clear cut forests. While they can be used for such a task, > they are quite inefficient at it. > #endif I only disagree in one point - /proc was a bad design from the beginning on, since you could expect to get what you have now there (Actually please see in archives those MANY MANY people on linux-kernel who where arguing against it before it ever got in... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
"H. Peter Anvin" wrote: > > Followup to: <[EMAIL PROTECTED]> > By author:John Byrne <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Anyway, one of the things I was hoping to find out by going to > > linux-kernel was if there was anything other than devfs in the offing: > > such a larger dev_t. So if anyone wants to chime in on things other than > > devfs, I'd certainly like to hear about it. > > > > A larger dev_t is a "must have" item for 2.5. And devfs doesn't provide NOTHING to facilitate it... -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
"H. Peter Anvin" wrote: Followup to: [EMAIL PROTECTED] By author:John Byrne [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Anyway, one of the things I was hoping to find out by going to linux-kernel was if there was anything other than devfs in the offing: such a larger dev_t. So if anyone wants to chime in on things other than devfs, I'd certainly like to hear about it. A larger dev_t is a "must have" item for 2.5. And devfs doesn't provide NOTHING to facilitate it... -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proc fs limit workaround?
Ricky Beam wrote: On Thu, 14 Sep 2000, Nick Pollitt wrote: ... And second, why is the 4K limit there in the first place? Primarily because it was never designed for 90% of the crap that's in there now. I have long hated the BS required to get more than 4k worth of stuff out of /proc. The way around the limit is not a solution, it's a hack. There's not atomicy for processing more than one page unless you go out of your way to deal with it. I've banged my head on the desk a few times because of this -- what happens when there's any delay between read()'s? *sigh* #ifdef RANT In case you haven't noticed a lot of present-day linux is a nice collection of hacks. This is the nature of code evilution -- I have to deal with this everyday (of course, I'm paid to.) procfs was actually a Very Good Thing(r) six or seven years ago when it was _designed_. Now look at it. I'm a perfectionist. I like things to be well planned, designed, and emplimented to do what they were designed to do. If you want it to do something else, return to the planning stage. For example, 747's weren't designed to clear cut forests. While they can be used for such a task, they are quite inefficient at it. #endif I only disagree in one point - /proc was a bad design from the beginning on, since you could expect to get what you have now there (Actually please see in archives those MANY MANY people on linux-kernel who where arguing against it before it ever got in... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: elevator code
Andi Kleen wrote: > > On Wed, Sep 13, 2000 at 04:29:18PM +0200, Andrea Arcangeli wrote: > > About B) I can' believe you seriously want to duplicate the merging code > > in each lowlevel driver given most of them could share the same code (as > > they're doing in linux). > > I guess it would just be a library call. e.g. the BSDs just have a disksort() > function that is called from the drivers as needed. For smart devices > with very intelligent firmware you simply do not call it (assuming you > have decently sized kiovec requests, with the current bh approach some > premerging is probably always needed) Yes - this is the cleanest solution in terms of code organization. You don't need to put it into a special struct and allways track it through pointer derefference - it's not a true callback in nature after all, since it doesn't need to be called asynchronously. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: elevator code
Andrea Arcangeli wrote: > > On Wed, 13 Sep 2000, Martin Dalecki wrote: > > >"Jeff V. Merkey" wrote: > > > >> lessons learned in live customer accounts. In NetWare, requests are > >> merged at A) the boundry between the File Cache and the I/O subsystem, > >> and B) in the drivers themselves and NOT THE ELEVATOR. > > > >Yes that's the proper place to do this. The generic elevator on a > > Jens is taking care of A) using kiobufs. We can't achieve A right now > because the I/O entity is 4k sized at max. That limitation is well known > and it cames from the old days and it's not a trivial one to address. It's > not a VM page-cache limitation but a blkdev API one. I agree it's silly to > split the big chunks in little bh and then re-merge them in one single > request later as we have to do. > > >*single* queue > >makes not much sense. Once ago I have just disabled it entierly and on a > > About B) I can' believe you seriously want to duplicate the merging code > in each lowlevel driver given most of them could share the same code (as > they're doing in linux). Yes seriously I would like to see it duplicated there. Becouse on this level it would be *far* simpler then on the generic level. And for a noabnormal configuration I guess the overall code size would be smaller then the generic aproach. Typically you just don't have that many *different* devices in your system: Either IDE or SCSI that's all. (OK that's just guessing...) > For the special ones you can just now use your own lowlevel driver > elevator/mergingcode/queuelength by intializing the callbacks > appropriately during driver intialization (NOTE: this is a new feature in > 2.4.x!) Could you do me the favour and just tell me inside which struct they are exactly? I would love it to try an elimination of the generic code on my system at home ;-). > I guess Netware doesn't have 402789 lines of blockdevice device drivers so > probably not doing code sharing properly is less an issue there. This is > just a guess, I may be wrong (in this case you should correct me, thanks). > > andrea@athlon:~ > wc -l kernel/devel/2.4.0-test8/drivers/block/* >kernel/devel/2.4.0-test8/drivers/ide/* kernel/devel/2.4.0-test8/drivers/i2o/* >kernel/devel/2.4.0-test8/drivers/scsi/* >kernel/devel/2.4.0-test8/drivers/block/paride/* >kernel/devel/2.4.0-test8/drivers/scsi/aic7xxx/* >kernel/devel/2.4.0-test8/drivers/scsi/pcmcia/*| tail -1 > wc: kernel/devel/2.4.0-test8/drivers/block/paride: Is a directory > wc: kernel/devel/2.4.0-test8/drivers/scsi/aic7xxx: Is a directory > wc: kernel/devel/2.4.0-test8/drivers/scsi/pcmcia: Is a directory > 402789 total > > Andrea -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: elevator code
Andrea Arcangeli wrote: On Wed, 13 Sep 2000, Martin Dalecki wrote: "Jeff V. Merkey" wrote: lessons learned in live customer accounts. In NetWare, requests are merged at A) the boundry between the File Cache and the I/O subsystem, and B) in the drivers themselves and NOT THE ELEVATOR. Yes that's the proper place to do this. The generic elevator on a Jens is taking care of A) using kiobufs. We can't achieve A right now because the I/O entity is 4k sized at max. That limitation is well known and it cames from the old days and it's not a trivial one to address. It's not a VM page-cache limitation but a blkdev API one. I agree it's silly to split the big chunks in little bh and then re-merge them in one single request later as we have to do. *single* queue makes not much sense. Once ago I have just disabled it entierly and on a About B) I can' believe you seriously want to duplicate the merging code in each lowlevel driver given most of them could share the same code (as they're doing in linux). Yes seriously I would like to see it duplicated there. Becouse on this level it would be *far* simpler then on the generic level. And for a noabnormal configuration I guess the overall code size would be smaller then the generic aproach. Typically you just don't have that many *different* devices in your system: Either IDE or SCSI that's all. (OK that's just guessing...) For the special ones you can just now use your own lowlevel driver elevator/mergingcode/queuelength by intializing the callbacks appropriately during driver intialization (NOTE: this is a new feature in 2.4.x!) Could you do me the favour and just tell me inside which struct they are exactly? I would love it to try an elimination of the generic code on my system at home ;-). I guess Netware doesn't have 402789 lines of blockdevice device drivers so probably not doing code sharing properly is less an issue there. This is just a guess, I may be wrong (in this case you should correct me, thanks). andrea@athlon:~ wc -l kernel/devel/2.4.0-test8/drivers/block/* kernel/devel/2.4.0-test8/drivers/ide/* kernel/devel/2.4.0-test8/drivers/i2o/* kernel/devel/2.4.0-test8/drivers/scsi/* kernel/devel/2.4.0-test8/drivers/block/paride/* kernel/devel/2.4.0-test8/drivers/scsi/aic7xxx/* kernel/devel/2.4.0-test8/drivers/scsi/pcmcia/*| tail -1 wc: kernel/devel/2.4.0-test8/drivers/block/paride: Is a directory wc: kernel/devel/2.4.0-test8/drivers/scsi/aic7xxx: Is a directory wc: kernel/devel/2.4.0-test8/drivers/scsi/pcmcia: Is a directory 402789 total Andrea -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: elevator code
"Jeff V. Merkey" wrote: > > Martin, > > I'm glad you are not still mad at me. :-) I hope this info was > helpful. Yes it was in fact this one of the more interresting posts in this thread. Thanks for the excellent reading. (However much of it sounded very familiar... maybe they learned the same lessons at Sun or Berkeley? ;-) The most important fact is that there is no misconception of blocks like there is currently under Linux. Linux is basically using FOUR different block concepts in case of the block device handling: 1. Filesystem iduced blocks. 2. physical block size. 3. buffer block size. Where in fact there should be only two: 1. FS block 2. physical block size. Merging 2. and 3. should be handled on the driver level. Interrestingliy enough the driver writers do it "intuitively" very freqeuntly indeed (ATAPI cd or mcdx for example). However they get beaten by the fact that sometimes the dividing line even between 1. and 2. isn't clean unter linux ;-)... insead of just basing anything on a basic buffer block size like 512 bytes. Interrestingly there is the same overgranulation in the concept of read-ahead under linux: 1. VFS read write - ahead. 1b. FS specific read write ahead. 2. Driver read write -ahead. 3. Physical device cache read write -ahead. Once again at least one point too much and then you could see the elevator as even just 4. some kind of wired variable block write/read-ahead... In fact most of the read aheads above are just foo due to the fact that the one enumerated as 3. is aleviating them. However due to "code impedancy", in esp. driver code impedancy I doubt seriously this will get ever cleaned up. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: More on 2.2.18pre2aa2
Hans Reiser wrote: > > I really think Rik has it right here. In particular, an MP3 player needs to be able >to say, I have > X milliseconds of buffer so make my worst case latency X milliseconds. The number >of requests is > the wrong metric, because the time required per request depends on disk geometry, >disk caching, etc. > No the problem is that an application should either: 1. Take full controll of the underlying system. 2. Don't care about selftuning the OS. Becouse that's what operating systems are for in first place: Letting the applications run without care of the underlying hardware. Linux is just mistaken by desing that there should be a generic elevator for any block device sitting on a single queue for any kind of attached device. Only device drivers know best how to handle queueing and stuff like this. The upper layers should only car about semanticall correctness of the request orders not about optimization of them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: elevator code
"Jeff V. Merkey" wrote: > lessons learned in live customer accounts. In NetWare, requests are > merged at A) the boundry between the File Cache and the I/O subsystem, > and B) in the drivers themselves and NOT THE ELEVATOR. Yes that's the proper place to do this. The generic elevator on a *single* queue makes not much sense. Once ago I have just disabled it entierly and on a system with swap on a separate disk and controller this was a performance *win*. Some of the FS code in esp. the ISO9660 does even under linux something *very* much like this. Many of the prop. cd-rom device drivers are basically emulating 512k block devices by reading ahead and throwing away data. There is really plenty of room for improvement here. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: More on 2.2.18pre2aa2
Andrea Arcangeli wrote: > > On Tue, 12 Sep 2000, Martin Dalecki wrote: > > >First of all: In the case of the mp3 player and such there is already a > >fine > >proper way to give it better chances on getting it's job done smooth - > >RT kernel sceduler priorities and proper IO buffering. I did something > >similiar > >to a GDI printer driver... > > Take 2.2.15, set a buffer of 128mbyte (of course assume your mp3 is larger > than 128mbyte :) and then run in background `cp /dev/zero .` in the same > fs where your mp3 file out of cache is living. Then you'll see why a large > buffer is useless if there's none kind of I/O fair scheduling into the > elevator. Repeat the same test in 2.2.16 then. > > The I/O latency Hans was taking about for the mp3 player, is the time it > takes for the buffer to become empty. I was talking about *proper* buffering not necessary *big* buffers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: More on 2.2.18pre2aa2
Chris Evans wrote: > > On Tue, 12 Sep 2000, Hans Reiser wrote: > > > I really think Rik has it right here. In particular, an MP3 player > > needs to be able to say, I have X milliseconds of buffer so make my > > worst case latency X milliseconds. The number of requests is the > > wrong metric, because the time required per request depends on disk > > geometry, disk caching, etc. > > Hi, > > We need to separate "what's a good idea" from "what's the best way to do > it". > > Sure, it's a good idea to get an mp3 player's I/O request serviced within > a certain amount of time. Is the best way to do that hacking the concept > of time into the elevator algorithm? That's currently under debate. > > In fact, the guarantee of I/O service time for a single process (mp3 > player) is pretty orthogonal to the per-device elevator settings. If you > have a certain block device set to a max latency of 0.25s, and lots of > processes are hammering the disk, then something will have to give, > i.e. under heavy load this setting will be useless and not honoured. > > The solution to this particular mp3 player scenario would be something > like the task scheduler policies we have. For example, maybe we could flag > a given process so that all it's I/O requests go to the head of the queue. > > Cheers > Chris First of all: In the case of the mp3 player and such there is already a fine proper way to give it better chances on getting it's job done smooth - RT kernel sceduler priorities and proper IO buffering. I did something similiar to a GDI printer driver... Second: The concept of time can give you very very nasty behaviour in even cases. Assume that a disc can only do 1 request per second. And then imagin a sceduling based on a 1+epsilon second... basically the disc will be run with half the speed it could. Those nasty integer arithmetics can you catch easly and mostly allways entierly unexpecting. Third: All you try to improve is the boundary case between an entierly overloaded system and a system which has a huge reserve to get the task done. I don't think you can find any "improvement" which will not just improve some cases and hurt some only slightly different cases badly. That's basically the same problem as with the paging strategy to follow. (However we have some kind of "common sense" in respect of this, despite the fact that linux does ignore it...) Firth: The most common solution for such boundary cases is some notion of cost optimization, like the nice value of a process or page age for example, or alternative some kind of choice between entierly different strategies (remember the term strategy routine) - all of them are just *relative* measures not absolute time constrains. Fifth: I think that such kind of IO behaviour control isn't something generic enough for the elevator - it should be all done on the device driver level, if at all. In fact you have already bad interactions between strategies of low level drivers and the high level code in Linux - like for example the "get from top of queue" or "don't get it from top of the IO queue" mess between IDE and SCSI middlelayers... (However this got a bit better recently.) -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: More on 2.2.18pre2aa2
Chris Evans wrote: On Tue, 12 Sep 2000, Hans Reiser wrote: I really think Rik has it right here. In particular, an MP3 player needs to be able to say, I have X milliseconds of buffer so make my worst case latency X milliseconds. The number of requests is the wrong metric, because the time required per request depends on disk geometry, disk caching, etc. Hi, We need to separate "what's a good idea" from "what's the best way to do it". Sure, it's a good idea to get an mp3 player's I/O request serviced within a certain amount of time. Is the best way to do that hacking the concept of time into the elevator algorithm? That's currently under debate. In fact, the guarantee of I/O service time for a single process (mp3 player) is pretty orthogonal to the per-device elevator settings. If you have a certain block device set to a max latency of 0.25s, and lots of processes are hammering the disk, then something will have to give, i.e. under heavy load this setting will be useless and not honoured. The solution to this particular mp3 player scenario would be something like the task scheduler policies we have. For example, maybe we could flag a given process so that all it's I/O requests go to the head of the queue. Cheers Chris First of all: In the case of the mp3 player and such there is already a fine proper way to give it better chances on getting it's job done smooth - RT kernel sceduler priorities and proper IO buffering. I did something similiar to a GDI printer driver... Second: The concept of time can give you very very nasty behaviour in even cases. Assume that a disc can only do 1 request per second. And then imagin a sceduling based on a 1+epsilon second... basically the disc will be run with half the speed it could. Those nasty integer arithmetics can you catch easly and mostly allways entierly unexpecting. Third: All you try to improve is the boundary case between an entierly overloaded system and a system which has a huge reserve to get the task done. I don't think you can find any "improvement" which will not just improve some cases and hurt some only slightly different cases badly. That's basically the same problem as with the paging strategy to follow. (However we have some kind of "common sense" in respect of this, despite the fact that linux does ignore it...) Firth: The most common solution for such boundary cases is some notion of cost optimization, like the nice value of a process or page age for example, or alternative some kind of choice between entierly different strategies (remember the term strategy routine) - all of them are just *relative* measures not absolute time constrains. Fifth: I think that such kind of IO behaviour control isn't something generic enough for the elevator - it should be all done on the device driver level, if at all. In fact you have already bad interactions between strategies of low level drivers and the high level code in Linux - like for example the "get from top of queue" or "don't get it from top of the IO queue" mess between IDE and SCSI middlelayers... (However this got a bit better recently.) -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: More on 2.2.18pre2aa2
Andrea Arcangeli wrote: On Tue, 12 Sep 2000, Martin Dalecki wrote: First of all: In the case of the mp3 player and such there is already a fine proper way to give it better chances on getting it's job done smooth - RT kernel sceduler priorities and proper IO buffering. I did something similiar to a GDI printer driver... Take 2.2.15, set a buffer of 128mbyte (of course assume your mp3 is larger than 128mbyte :) and then run in background `cp /dev/zero .` in the same fs where your mp3 file out of cache is living. Then you'll see why a large buffer is useless if there's none kind of I/O fair scheduling into the elevator. Repeat the same test in 2.2.16 then. The I/O latency Hans was taking about for the mp3 player, is the time it takes for the buffer to become empty. I was talking about *proper* buffering not necessary *big* buffers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: elevator code
"Jeff V. Merkey" wrote: lessons learned in live customer accounts. In NetWare, requests are merged at A) the boundry between the File Cache and the I/O subsystem, and B) in the drivers themselves and NOT THE ELEVATOR. Yes that's the proper place to do this. The generic elevator on a *single* queue makes not much sense. Once ago I have just disabled it entierly and on a system with swap on a separate disk and controller this was a performance *win*. Some of the FS code in esp. the ISO9660 does even under linux something *very* much like this. Many of the prop. cd-rom device drivers are basically emulating 512k block devices by reading ahead and throwing away data. There is really plenty of room for improvement here. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: More on 2.2.18pre2aa2
Hans Reiser wrote: I really think Rik has it right here. In particular, an MP3 player needs to be able to say, I have X milliseconds of buffer so make my worst case latency X milliseconds. The number of requests is the wrong metric, because the time required per request depends on disk geometry, disk caching, etc. No the problem is that an application should either: 1. Take full controll of the underlying system. 2. Don't care about selftuning the OS. Becouse that's what operating systems are for in first place: Letting the applications run without care of the underlying hardware. Linux is just mistaken by desing that there should be a generic elevator for any block device sitting on a single queue for any kind of attached device. Only device drivers know best how to handle queueing and stuff like this. The upper layers should only car about semanticall correctness of the request orders not about optimization of them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: elevator code
"Jeff V. Merkey" wrote: Martin, I'm glad you are not still mad at me. :-) I hope this info was helpful. Yes it was in fact this one of the more interresting posts in this thread. Thanks for the excellent reading. (However much of it sounded very familiar... maybe they learned the same lessons at Sun or Berkeley? ;-) The most important fact is that there is no misconception of blocks like there is currently under Linux. Linux is basically using FOUR different block concepts in case of the block device handling: 1. Filesystem iduced blocks. 2. physical block size. 3. buffer block size. Where in fact there should be only two: 1. FS block 2. physical block size. Merging 2. and 3. should be handled on the driver level. Interrestingliy enough the driver writers do it "intuitively" very freqeuntly indeed (ATAPI cd or mcdx for example). However they get beaten by the fact that sometimes the dividing line even between 1. and 2. isn't clean unter linux ;-)... insead of just basing anything on a basic buffer block size like 512 bytes. Interrestingly there is the same overgranulation in the concept of read-ahead under linux: 1. VFS read write - ahead. 1b. FS specific read write ahead. 2. Driver read write -ahead. 3. Physical device cache read write -ahead. Once again at least one point too much and then you could see the elevator as even just 4. some kind of wired variable block write/read-ahead... In fact most of the read aheads above are just foo due to the fact that the one enumerated as 3. is aleviating them. However due to "code impedancy", in esp. driver code impedancy I doubt seriously this will get ever cleaned up. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
Gary Lawrence Murphy wrote: > The analogy to typing hex codes or toggling code at the console is > also apt. Unix ascended over Multix in no small part because of C, > which drew sneers from the trad programmer of the day. Personally, I > tend to debug intuitively based on my knowledge of code, but not > exclusively. In my 25 years in this business, I have seen amazing > things done with debuggers, things that had stumped whole teams of > very good programmers. Intuition still plays a vital role, but gdb in > the right hands can prove things that would take months of code > tweaking to do by hand. Maybe it's that just 25 years in this industry made you for Alzheimer, since you should know that the first versions of UNIX where actually written in plain assembler. So C certainly isn't what made for it's success in first place. And then please just compare C with any other modern programming language like pascal/modula/java/C++/objective/C/ADA or anything elese. From all of them C is the most "assembler alike" language and still the most widely used for OS programming out there: BeOS, NT, UNIX, QNX, VMS, CP/M, DOS, Mach, and so on and so on. Second: GDB is DREADFULL in terms of user friendliness... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
Gary Lawrence Murphy wrote: The analogy to typing hex codes or toggling code at the console is also apt. Unix ascended over Multix in no small part because of C, which drew sneers from the trad programmer of the day. Personally, I tend to debug intuitively based on my knowledge of code, but not exclusively. In my 25 years in this business, I have seen amazing things done with debuggers, things that had stumped whole teams of very good programmers. Intuition still plays a vital role, but gdb in the right hands can prove things that would take months of code tweaking to do by hand. Maybe it's that just 25 years in this industry made you for Alzheimer, since you should know that the first versions of UNIX where actually written in plain assembler. So C certainly isn't what made for it's success in first place. And then please just compare C with any other modern programming language like pascal/modula/java/C++/objective/C/ADA or anything elese. From all of them C is the most "assembler alike" language and still the most widely used for OS programming out there: BeOS, NT, UNIX, QNX, VMS, CP/M, DOS, Mach, and so on and so on. Second: GDB is DREADFULL in terms of user friendliness... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Simon Richter wrote: > > On Thu, 7 Sep 2000, Martin Dalecki wrote: > > > > I've done an implementation of some of the Win32 "system calls" in a kernel > > > module in an attempt to speed up Wine. > > > 1. Linux is UNIX not NT... (in terms of API) > > What about a Win32 personality? > > > 2. WINE in itself is barely usefull - even in fact non existant, since > > there is > >no official stable release out there. > > Erm, ever seen Adobe Photopaint for Linux? It's basically the Windows .exe > plus a wine that can do all the syscalls Photopaint needs. Yes seen. Huge bloadted instabile piece of hack on top of a hack on top of a hack... If I need NT I can use it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Howells wrote: > > I've done an implementation of some of the Win32 "system calls" in a kernel > module in an attempt to speed up Wine. Please by no way don't include this patch into the official tree. It's insane due to the following: 1. Linux is UNIX not NT... (in terms of API) 2. WINE in itself is barely usefull - even in fact non existant, since there is no official stable release out there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: > > On Wed, 6 Sep 2000, Martin Dalecki wrote: > > > > > So may I just suggest to repleace the usage of cpp at all with something > > more > > suitable for the task at hand and with a much more regular/stringent > > syntax > > better fitting into the syntax of the pure C language like m4 for > > example? > > > > No. Still "better tools" variant. Check blk_dev_init() and tell me how do > you like the end of this function (drivers/block/ll_rw_blk.c). BTW, check Yes you are right here I don't like this particular piece of code in esp since: 1. The macro hackery may very well be replaced with "vanishing macros" at the declaration level. 2. This is basically an fully unrolled loop of calls into a function pointer table. 3. It's making the corresponding driver code non self contained. > how many of these CONFIG_... are needed anywhere on C level. Hint: see > module_init macro. Yes I like the introduction of the ld hackere there very much: It's basically solving the problems 1. 2. and 3. by doing the proper thing ;-) i.e. provide an statically initialized list of addresses and call them out of a loop. > > The main problem with the CONFIG_ blah's isn't either the syntax nor > > they current usage - the problem is inherent to the simple fact > > that the number of possible combinations is of a very high order due > > to simple combinatorics. > > It's not a fact, it's a problem... It doesn't _have_ to be very high > order on cc level. ld - sure, but that's much simpler to deal with. But in some cases the driver api in linux are not quite supportiv for this. Please have a look at the strattegy routine (please allow me to use the proper UNIX terminology here ;-) declaration hackery inside of ide.h, oh sorry it gote moved and I can't quite find it again... ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: > > On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote: > > > We could use some more infrastructure here. > > > > (1) A 'make randomconfig' tool that generates a random configuration. > > > > (2) Make the architecture a configuration variable (!) > > > > (3) A collection of RPM's so that people can download and install > > all the cross tools easily. > > (0) knowledge that CONFIG_FOO15 doesn't affect anything other than set of > source files being compiled. > > Providing better tools is nice, but simplifying the problem domain > sometimes pays better... So may I just suggest to repleace the usage of cpp at all with something more suitable for the task at hand and with a much more regular/stringent syntax better fitting into the syntax of the pure C language like m4 for example? I think Java has the perfect solution for conditional compilation - don't make it possible at al in a sane standard way! Coditional compilation is evil like gotos (despite the fact that even every pascal implementation out there provided them). The main problem with the CONFIG_ blah's isn't either the syntax nor they current usage - the problem is inherent to the simple fact that the number of possible combinations is of a very high order due to simple combinatorics. Hmm maybe the first irony is a quite serious suggestion at least in the case of CONFIG_ options? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Remarks about sigtestsetmask()
Alan Cox wrote: > > > 1. This function is only used in the poorly maintained ftape driver. > >The usage there isn't appriopriate for modern kernels. > > The ftape driver isnt exactly poorly maintained. Its just not integrated into > 2.3/2.4. Ftape 4.0 is still elsewhere This is wrong, since last time I checked the maintainer stepped back from the tast. And I understand reintegration into the mainstream kernel proper maintainance as well. (The two versions are *VERY* different). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Remarks about sigtestsetmask()
Alan Cox wrote: 1. This function is only used in the poorly maintained ftape driver. The usage there isn't appriopriate for modern kernels. The ftape driver isnt exactly poorly maintained. Its just not integrated into 2.3/2.4. Ftape 4.0 is still elsewhere This is wrong, since last time I checked the maintainer stepped back from the tast. And I understand reintegration into the mainstream kernel proper maintainance as well. (The two versions are *VERY* different). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote: We could use some more infrastructure here. (1) A 'make randomconfig' tool that generates a random configuration. (2) Make the architecture a configuration variable (!) (3) A collection of RPM's so that people can download and install all the cross tools easily. (0) knowledge that CONFIG_FOO15 doesn't affect anything other than set of source files being compiled. Providing better tools is nice, but simplifying the problem domain sometimes pays better... IRONY ON So may I just suggest to repleace the usage of cpp at all with something more suitable for the task at hand and with a much more regular/stringent syntax better fitting into the syntax of the pure C language like m4 for example? /IRONY OFF EVEN MORE IRONY ON I think Java has the perfect solution for conditional compilation - don't make it possible at al in a sane standard way! Coditional compilation is evil like gotos (despite the fact that even every pascal implementation out there provided them). /EVEN MORE IRONY OFF The main problem with the CONFIG_ blah's isn't either the syntax nor they current usage - the problem is inherent to the simple fact that the number of possible combinations is of a very high order due to simple combinatorics. Hmm maybe the first irony is a quite serious suggestion at least in the case of CONFIG_ options? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: On Wed, 6 Sep 2000, Martin Dalecki wrote: IRONY ON So may I just suggest to repleace the usage of cpp at all with something more suitable for the task at hand and with a much more regular/stringent syntax better fitting into the syntax of the pure C language like m4 for example? /IRONY OFF No. Still "better tools" variant. Check blk_dev_init() and tell me how do you like the end of this function (drivers/block/ll_rw_blk.c). BTW, check Yes you are right here I don't like this particular piece of code in esp since: 1. The macro hackery may very well be replaced with "vanishing macros" at the declaration level. 2. This is basically an fully unrolled loop of calls into a function pointer table. 3. It's making the corresponding driver code non self contained. how many of these CONFIG_... are needed anywhere on C level. Hint: see module_init macro. Yes I like the introduction of the ld hackere there very much: It's basically solving the problems 1. 2. and 3. by doing the proper thing ;-) i.e. provide an statically initialized list of addresses and call them out of a loop. The main problem with the CONFIG_ blah's isn't either the syntax nor they current usage - the problem is inherent to the simple fact that the number of possible combinations is of a very high order due to simple combinatorics. It's not a fact, it's a problem... It doesn't _have_ to be very high order on cc level. ld - sure, but that's much simpler to deal with. But in some cases the driver api in linux are not quite supportiv for this. Please have a look at the strattegy routine (please allow me to use the proper UNIX terminology here ;-) declaration hackery inside of ide.h, oh sorry it gote moved and I can't quite find it again... ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: > > On Wed, 6 Sep 2000, Martin Dalecki wrote: > > > Easy - the same way you do for cross compilation. Basically just: > > > > export CC=g++ --some-magic-long-option-i-dont-remember; make > > ... and you still have only a subset of the tree, simply because it is fed > through cpp before it reaches the parser. And cpp cuts away many pieces. > Different config options and you've got a different subset. Good luck > providing the coverage. That's not quite the problem - with the exception of the boundary cases of compleatly broken CONFIG_BLAH combinations... You have the fine .confg file there you know... Count them n and take the n! for all the possible config choices. Then you will see that THERE CAN'T be any better automatic approach then just what I have described above (ie. going directly into the compiler) and doing the CONFIG_ handling by hand. (I mean scripting for the most appriopriate choices...) > > Basically I will just guess: The next maybe non free version of > > source navigator will use the mechanism I have just described above. > > So maybe there is already someone at RedHat doing exactly this work > > already ;-). > > Physically impossible without a major cleanup of the tree. Yeah... let me be nice to you as well Source Navigator got released for free - since the project died inside RedHat anyway due to the fact that it's full of the worst coding practices I ever saw - like for example literally copy and paste Tcl/Tk/iTcl and such. So instead of buring it they just threw it "out of the window" for "free". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Remarks about sigtestsetmask()
1. This function is only used in the poorly maintained ftape driver. The usage there isn't appriopriate for modern kernels. 2. This function acts only on the sig set of the current process, so the first parameter should be just a porinter to current, instead of currgen->sigset. So it should be presumably removed all-together. -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel debugging
Elmer Joandi wrote:
>
> > understanding the
> > > underlying principles and the code.
>
> Speaking about that, I have been long time dreaming
> about following strict standard template for linux kernel functions:
> (macroplay intended)
> --
> INLINE(context,level,for_speed, fixed) returntype functionname
> (PARM(parameters)){
> DEBUG(ENTRY,SUBSYSTEM, module, functionname);
> /* function body starts */
> do something
> do something
> on success goto ok;
> on failure goto failure_reason_name;
> /* function body ends */
> ok:
> on ok do something
> DEBUG(EXIT,SUBSYSTEM, module functionname, OK);
> exit or return whatever
> failure_reason_name;
> on this reason do something
> DEBUG(EXIT,SUBSYSTEM, module, functionname, reason_name);
> exit or return whatever
> failure_reason_name1;
> on this reason do something
> DEBUG(EXIT,SUBSYSTEM, module, functionname, reason_name1);
> exit or return whatever
> };
> --
Please have a tought look at the floppy tape streamer driver to see why
this
is a BAD IDEA.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Linus Torvalds wrote: > > On Tue, 5 Sep 2000, Alexander Viro wrote: > > > > > > What would be acceptable is something that understands C, and that can be > > > used to follow these things. Like "tags". > > > > I don't like hungarian notation too, but tags is out of question, > > unfortunately. Too much preprocessor abuse in include/*/*.h. > > Notice the _like_ tags. > > Basically, what I'm saying is that I understand why people want to grep > for specific uses, but I'm saying that a pure textual greap that doesn't > understand the context is not an option - because it implies adding > "cruft" to everything you want to grep for. Not for readability, but for > greppability. > > And I'm saying that if people really want to do this, then use the > computer to do it for you, having more than just "grep", and making your > tools aware of it. There is some facility allowing to implement this kind of things in the C++ part of the most recent EGCS version which makes implementing such things "relatively" easy - basiclly there is the provision to dump the parser trees as easy to process ascii text already there. Basically I think this dererr of syntactical analysis can only be implementen by serious help from the compiler. Maybe this is a new argument to facilitate at least correct syntactical processing of the kernel by the C++ flavour of EGCS? Please note that this wouldn't need to generate really executable code - which as we all know is rather difficult due to the extensive runtime support as well as ehm. the wired calling conventions C++ is oppressing on the compiler... Just correct syntactical processing is all what's neccessary - this isn't THAT difficult to achive ;-). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
"Jeff V. Merkey" wrote: > > Ingo Molnar wrote: > > > > On Tue, 5 Sep 2000, Jeff V. Merkey wrote: > > > > > Your arguments are personal, not technical. [...] > > > > no, my arguments are technical, but are simply focused towards the > > conceptual (horizontal) development of Linux, not the vertical > > development of Linux (drivers) and support issues. > > They seem focused on keeping us in the dark ages. We need tools to make > it faster and easier for folks to perform kernel development and make > field support of Linux easier. No I don't agree. There are other areas where fast progress is by far more desirable then inside the kernel - PLEASE KEEP THE KERNEL dev. slow - which in the practice automatically translates into STABILITY of interfaces ;-). What's only needed fast are just device drivers. I don't care whatever it takes 2 or 3 years between major kernel releases - even this is twice the freq of NT updates already! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
Ingo Molnar wrote: > > On Tue, 5 Sep 2000, Andi Kleen wrote: > > > My point was basically that omitting useful debugging tools makes it > > not any less likely that people use the (A) strategy (easy fix instead > > of real understanding). For some people it is so painfull to work with > > raw dumps that they want to get out of that pain as quickly as > > possible, like with just adding an if (!ptr) return; and be done with > > it. > > well, they will sooner or later notice that it's easier to fix bugs by > following the development of the kernel and understanding the underlying > principles and the code. As elitist as it might seem, we rather need 10 > highly skilled developers who understand the kernel than 100 moderately > skilled ones who know how to operate a kernel debugger and barely anything > else. [this is not an insult towards people with less experience - having > less experience is just a temporary stage of a process, nothing else. But > if it becomes the end station thats a problem IMHO.] > > Ingo There is a nice discussion about the online-debugging vers. the "doing it the hard way" approach in some software engineering books out there. (Sorry I don't have them here at hand, so I can't give an exact refference - it was either the famous "Mythical Man Month" or "Warum is Software so Teuer und andere Mythen der Informationstechnologie" by some other guy whose name I don't remember ;-). However I'm quite sure someone here will remember it well... Basically in the book I have in mind the author was describing the result's of a spinoff company from IBM which was trying to make some money on the added facility of "heart surgery" to some early IBM OS. (IBM did release them just for the price of a symbolic 1$)/ Basically after some time they have realized that yes casual debugging was easier and more productive, but after long the statistical view showed that the code quality was rather degrading by using on the fly debuggers instead of improving. --- Sometimes the obvious isn't the RIGHT THING becouse most of the time the easy fixes are just band aids hiding the trough problems. Therefore I would rather like to back-up the position of Ingo. And finally I would like to emphasize that every singe additional facility doesn't come free - It's adding complexity which is a source of possible problems in itself. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Linus Torvalds wrote: On Tue, 5 Sep 2000, Alexander Viro wrote: What would be acceptable is something that understands C, and that can be used to follow these things. Like "tags". I don't like hungarian notation too, but tags is out of question, unfortunately. Too much preprocessor abuse in include/*/*.h. Notice the _like_ tags. Basically, what I'm saying is that I understand why people want to grep for specific uses, but I'm saying that a pure textual greap that doesn't understand the context is not an option - because it implies adding "cruft" to everything you want to grep for. Not for readability, but for greppability. And I'm saying that if people really want to do this, then use the computer to do it for you, having more than just "grep", and making your tools aware of it. There is some facility allowing to implement this kind of things in the C++ part of the most recent EGCS version which makes implementing such things "relatively" easy - basiclly there is the provision to dump the parser trees as easy to process ascii text already there. Basically I think this dererr of syntactical analysis can only be implementen by serious help from the compiler. Maybe this is a new argument to facilitate at least correct syntactical processing of the kernel by the C++ flavour of EGCS? Please note that this wouldn't need to generate really executable code - which as we all know is rather difficult due to the extensive runtime support as well as ehm. the wired calling conventions C++ is oppressing on the compiler... Just correct syntactical processing is all what's neccessary - this isn't THAT difficult to achive ;-). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Remarks about sigtestsetmask()
1. This function is only used in the poorly maintained ftape driver. The usage there isn't appriopriate for modern kernels. 2. This function acts only on the sig set of the current process, so the first parameter should be just a porinter to current, instead of currgen-sigset. So it should be presumably removed all-together. -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: On Wed, 6 Sep 2000, Martin Dalecki wrote: Easy - the same way you do for cross compilation. Basically just: export CC=g++ --some-magic-long-option-i-dont-remember; make ... and you still have only a subset of the tree, simply because it is fed through cpp before it reaches the parser. And cpp cuts away many pieces. Different config options and you've got a different subset. Good luck providing the coverage. That's not quite the problem - with the exception of the boundary cases of compleatly broken CONFIG_BLAH combinations... You have the fine .confg file there you know... Count them n and take the n! for all the possible config choices. Then you will see that THERE CAN'T be any better automatic approach then just what I have described above (ie. going directly into the compiler) and doing the CONFIG_ handling by hand. (I mean scripting for the most appriopriate choices...) Basically I will just guess: The next maybe non free version of source navigator will use the mechanism I have just described above. So maybe there is already someone at RedHat doing exactly this work already ;-). Physically impossible without a major cleanup of the tree. Yeah... let me be nice to you as well Source Navigator got released for free - since the project died inside RedHat anyway due to the fact that it's full of the worst coding practices I ever saw - like for example literally copy and paste Tcl/Tk/iTcl and such. So instead of buring it they just threw it "out of the window" for "free". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel debugging
Elmer Joandi wrote:
understanding the
underlying principles and the code.
Speaking about that, I have been long time dreaming
about following strict standard template for linux kernel functions:
(macroplay intended)
--
INLINE(context,level,for_speed, fixed) returntype functionname
(PARM(parameters)){
DEBUG(ENTRY,SUBSYSTEM, module, functionname);
/* function body starts */
do something
do something
on success goto ok;
on failure goto failure_reason_name;
/* function body ends */
ok:
on ok do something
DEBUG(EXIT,SUBSYSTEM, module functionname, OK);
exit or return whatever
failure_reason_name;
on this reason do something
DEBUG(EXIT,SUBSYSTEM, module, functionname, reason_name);
exit or return whatever
failure_reason_name1;
on this reason do something
DEBUG(EXIT,SUBSYSTEM, module, functionname, reason_name1);
exit or return whatever
};
--
Please have a tought look at the floppy tape streamer driver to see why
this
is a BAD IDEA.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
Ingo Molnar wrote: On Tue, 5 Sep 2000, Andi Kleen wrote: My point was basically that omitting useful debugging tools makes it not any less likely that people use the (A) strategy (easy fix instead of real understanding). For some people it is so painfull to work with raw dumps that they want to get out of that pain as quickly as possible, like with just adding an if (!ptr) return; and be done with it. well, they will sooner or later notice that it's easier to fix bugs by following the development of the kernel and understanding the underlying principles and the code. As elitist as it might seem, we rather need 10 highly skilled developers who understand the kernel than 100 moderately skilled ones who know how to operate a kernel debugger and barely anything else. [this is not an insult towards people with less experience - having less experience is just a temporary stage of a process, nothing else. But if it becomes the end station thats a problem IMHO.] Ingo There is a nice discussion about the online-debugging vers. the "doing it the hard way" approach in some software engineering books out there. (Sorry I don't have them here at hand, so I can't give an exact refference - it was either the famous "Mythical Man Month" or "Warum is Software so Teuer und andere Mythen der Informationstechnologie" by some other guy whose name I don't remember ;-). However I'm quite sure someone here will remember it well... Basically in the book I have in mind the author was describing the result's of a spinoff company from IBM which was trying to make some money on the added facility of "heart surgery" to some early IBM OS. (IBM did release them just for the price of a symbolic 1$)/ Basically after some time they have realized that yes casual debugging was easier and more productive, but after long the statistical view showed that the code quality was rather degrading by using on the fly debuggers instead of improving. --- Sometimes the obvious isn't the RIGHT THING becouse most of the time the easy fixes are just band aids hiding the trough problems. Therefore I would rather like to back-up the position of Ingo. And finally I would like to emphasize that every singe additional facility doesn't come free - It's adding complexity which is a source of possible problems in itself. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
"Jeff V. Merkey" wrote: Ingo Molnar wrote: On Tue, 5 Sep 2000, Jeff V. Merkey wrote: Your arguments are personal, not technical. [...] no, my arguments are technical, but are simply focused towards the conceptual (horizontal) development of Linux, not the vertical development of Linux (drivers) and support issues. They seem focused on keeping us in the dark ages. We need tools to make it faster and easier for folks to perform kernel development and make field support of Linux easier. No I don't agree. There are other areas where fast progress is by far more desirable then inside the kernel - PLEASE KEEP THE KERNEL dev. slow - which in the practice automatically translates into STABILITY of interfaces ;-). What's only needed fast are just device drivers. I don't care whatever it takes 2 or 3 years between major kernel releases - even this is twice the freq of NT updates already! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
