Re: RFD: Kernel release numbering
On Thu, 03 Mar 2005 14:23:37 +0100, Rene Herman
<[EMAIL PROTECTED]> wrote:
>Jeff Garzik wrote:
>
>> Rene Herman wrote:
>>
>>> Doing -pre and real -rc will get you more testers for -rc. Whether or
>>
>>> Add in the fourth level .k releases for real problematic bugs found
>>> after release as you did with 2.6.8.1, and I believe things should work.
>>
>> Precisely.
>
>I assume that one of the main problems with doing -pre is that actually
>doing a real -rc isn't much fun -- I can certainly understand that
>sitting around twiddling your thumbs by decree every few weeks is not a
>good model.
>
>You commented on the .k 4th level releases being an actual branch, BK
>wise. To not let the forced thumb-twiddling -rc period be a problem,
>this branch could happen at -rc1, after which Linus is again free to go
>merge up stuff into mainline for the next one, if he wants to.
>
>That's to say, I propose Linus doesn't change _anything_ other than
>renaming his -rc's -pre's, and his final -rc1 (well, and making it a
>branch if -final isn't a branch now, sorry, not a clue).
>
>The -rc branch then just sits there, and if nothing turns up that needs
>an -rc2, it gets released as final, and possibly onto .1, .2 and so on
>if useful or need be.
>
>Now, coaching that -rc branch from -rc1 through maybe -rcN to -final and
>possibly beyond may not be something Linus wants to do. The -rc branch
>would by definition see _no_ activity other than the really needed so I
>don't believe it would be much of a burden time-wise, but it is in fact
>not unlike what Alan is already doing with -ac. So, if Linus doesn't
>want that job, Alan may? Or someone else?
>
>Summarising:
>
>- Linus:
>
> 1) rename 2.6.N-rcX to 2.6.N-preX
> 2) when you'd now release, branch off, release as -rc1
> 3) go on with 2.6.(N+1)-pre1
>
>- Linus, Alan, or whoever else wants the job:
>
> 1) release -rc{2,3,...} only if needed.
> 2) release 2.6.N
> 3) do a 2.6.N.{1,2,...} only if needed.
>
>Is this sane? The advantage is, real -pre's and -rc's which will get
>more people onboard testing -rc, and hopefully without annoying Linus
>with real no-changing -rc's. How many more, enough or not, remains to be
> seen but certainly more.
One way to handle the transition into bug-fix only would be to turn
the tree over to the $stability crew at that moment. They would have
the job of nursing it to stability under the given ground rules.
john alvord
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Thu, 03 Mar 2005 14:23:37 +0100, Rene Herman
[EMAIL PROTECTED] wrote:
Jeff Garzik wrote:
Rene Herman wrote:
Doing -pre and real -rc will get you more testers for -rc. Whether or
Add in the fourth level .k releases for real problematic bugs found
after release as you did with 2.6.8.1, and I believe things should work.
Precisely.
I assume that one of the main problems with doing -pre is that actually
doing a real -rc isn't much fun -- I can certainly understand that
sitting around twiddling your thumbs by decree every few weeks is not a
good model.
You commented on the .k 4th level releases being an actual branch, BK
wise. To not let the forced thumb-twiddling -rc period be a problem,
this branch could happen at -rc1, after which Linus is again free to go
merge up stuff into mainline for the next one, if he wants to.
That's to say, I propose Linus doesn't change _anything_ other than
renaming his -rc's -pre's, and his final -rc1 (well, and making it a
branch if -final isn't a branch now, sorry, not a clue).
The -rc branch then just sits there, and if nothing turns up that needs
an -rc2, it gets released as final, and possibly onto .1, .2 and so on
if useful or need be.
Now, coaching that -rc branch from -rc1 through maybe -rcN to -final and
possibly beyond may not be something Linus wants to do. The -rc branch
would by definition see _no_ activity other than the really needed so I
don't believe it would be much of a burden time-wise, but it is in fact
not unlike what Alan is already doing with -ac. So, if Linus doesn't
want that job, Alan may? Or someone else?
Summarising:
- Linus:
1) rename 2.6.N-rcX to 2.6.N-preX
2) when you'd now release, branch off, release as -rc1
3) go on with 2.6.(N+1)-pre1
- Linus, Alan, or whoever else wants the job:
1) release -rc{2,3,...} only if needed.
2) release 2.6.N
3) do a 2.6.N.{1,2,...} only if needed.
Is this sane? The advantage is, real -pre's and -rc's which will get
more people onboard testing -rc, and hopefully without annoying Linus
with real no-changing -rc's. How many more, enough or not, remains to be
seen but certainly more.
One way to handle the transition into bug-fix only would be to turn
the tree over to the $stability crew at that moment. They would have
the job of nursing it to stability under the given ground rules.
john alvord
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wed, 06 Jun 2001 11:31:28 -0400, Derek Glidden <[EMAIL PROTECTED]> wrote: > >I'm beginning to be amazed at the Linux VM hackers' attitudes regarding >this problem. I expect this sort of behaviour from academics - ignoring >real actual problems being reported by real actual people really and >actually experiencing and reporting them because "technically" or >"theoretically" they "shouldn't be an issue" or because "the "literature >[documentation] says otherwise - but not from this group. There have been multiple comments that a fix for the problem is forthcoming. Is there some reason you have to keep talking about it? John alvord - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wed, 06 Jun 2001 11:31:28 -0400, Derek Glidden [EMAIL PROTECTED] wrote: I'm beginning to be amazed at the Linux VM hackers' attitudes regarding this problem. I expect this sort of behaviour from academics - ignoring real actual problems being reported by real actual people really and actually experiencing and reporting them because technically or theoretically they shouldn't be an issue or because the literature [documentation] says otherwise - but not from this group. There have been multiple comments that a fix for the problem is forthcoming. Is there some reason you have to keep talking about it? John alvord - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a typewriter
On Fri, 11 May 2001 11:07:45 -0500, [EMAIL PROTECTED] wrote: > > >On 05/10/2001 at 06:20:34 PM Hacksaw <[EMAIL PROTECTED]> wrote: > >My point is that someone who sees the "typewriter" message and doesn't >understand it will have to dig a bit to find out what it means. Finding it >almost certainly will involve uncovering some of the history and folklore of >Unix. In the "Intro to Unix" classes I've taught over the years, I've always >made a point of explaining the background of things like this -- such as the >relation of grep to the g/re/p expression of ed, ex and vi; where biff got its >name; what the letters stand for in awk; why creat doesn't end in an "e;" and so >forth. I tell the class that Unix has quirky, eccentric, whimsical elements >because many of the things in it were written by quirky, eccentric, or whimsical >people. The comment at the bottom of some versions of the tunefs man page (such >as the HP-UX version) is an example I like to use: "You can tune a file system, >but you can't tune a fish." I tell them they'll understand the Unix way of >thinking faster if they approach it with an inquisitive, playful spirit rather >than as a stuffy business system. It's supposed to be correct; it's supposed to >be efficient; but it's also supposed to be fun, and sometimes the fun is worth >sacrificing a little of the other qualities in trivial areas. > >I guess what I'm trying to say is that "Life With Unix" should be required >reading for anyone who goes near a Unix (or Linux) system. David N. Smith, an IBM researcher, wrote that we should preserve the past for the criticism of the future. john alvord - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a typewriter
On Fri, 11 May 2001 11:07:45 -0500, [EMAIL PROTECTED] wrote: On 05/10/2001 at 06:20:34 PM Hacksaw [EMAIL PROTECTED] wrote: My point is that someone who sees the typewriter message and doesn't understand it will have to dig a bit to find out what it means. Finding it almost certainly will involve uncovering some of the history and folklore of Unix. In the Intro to Unix classes I've taught over the years, I've always made a point of explaining the background of things like this -- such as the relation of grep to the g/re/p expression of ed, ex and vi; where biff got its name; what the letters stand for in awk; why creat doesn't end in an e; and so forth. I tell the class that Unix has quirky, eccentric, whimsical elements because many of the things in it were written by quirky, eccentric, or whimsical people. The comment at the bottom of some versions of the tunefs man page (such as the HP-UX version) is an example I like to use: You can tune a file system, but you can't tune a fish. I tell them they'll understand the Unix way of thinking faster if they approach it with an inquisitive, playful spirit rather than as a stuffy business system. It's supposed to be correct; it's supposed to be efficient; but it's also supposed to be fun, and sometimes the fun is worth sacrificing a little of the other qualities in trivial areas. I guess what I'm trying to say is that Life With Unix should be required reading for anyone who goes near a Unix (or Linux) system. David N. Smith, an IBM researcher, wrote that we should preserve the past for the criticism of the future. john alvord - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wow! Is memory ever cheap!
On Tue, 8 May 2001 22:22:10 -0700, Larry McVoy <[EMAIL PROTECTED]> wrote: > >Just to make sure you understand: I think ECC is a fine thing. If I'm >running systems with no other integrity checks, I'll take ECC and like it. >However, having ECC does not mean that I trust that my data is safe, >that is most certainly not a true statement. The bus, the disks, the >disk controller, the disk driver, the buffer cache, etc, can all corrupt >the data. Oh, yeah, let's not forget NFS. I have seen each and every >one of those things corrupt data. This is an interesting observation of a truth that was well known in the second generation computers of the 1950s and 1960s. I first worked at John Hancock... they had a bunch of 7074 machines. All those systems made use of programmed checksums in each tape block and in each full file. The reason was that those machines did not have ECC... they did have parity checking if I remember right. With IBM's third generation computers (S/360s) and probably other manufacturers, ECC became a standard feature. Parity checking was added through different data paths such as channel memory, buffer memory, etc. There was so much protection added that the programmed checksums became superfluous. There were still odd moments. I remember working on an Amdahl computer problem where some internal data paths... where the contents of one register moved to an internal storage area... and the path did not have parity. There was a machine fault... the path was electrically open, so the contents of the register always became zero. But since it wasn't parity checked, there was no machine check. I remember another problem on the IBM 3033. Cosmic rays (really) caused one bit errors in channel memory. That was parity but not ECC so you got a weird channel check. Back at the diagnosis ranch, the board looked good. It was only when someone noticed that the rate of such problems was proportional to the height above sea level that the light bulb went on. The lesson is that when paths are not checked, hardware or software, data being held or transformed can change. Old lesson but a good one to know. john alvord - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wow! Is memory ever cheap!
On Tue, 8 May 2001 22:22:10 -0700, Larry McVoy [EMAIL PROTECTED] wrote: Just to make sure you understand: I think ECC is a fine thing. If I'm running systems with no other integrity checks, I'll take ECC and like it. However, having ECC does not mean that I trust that my data is safe, that is most certainly not a true statement. The bus, the disks, the disk controller, the disk driver, the buffer cache, etc, can all corrupt the data. Oh, yeah, let's not forget NFS. I have seen each and every one of those things corrupt data. This is an interesting observation of a truth that was well known in the second generation computers of the 1950s and 1960s. I first worked at John Hancock... they had a bunch of 7074 machines. All those systems made use of programmed checksums in each tape block and in each full file. The reason was that those machines did not have ECC... they did have parity checking if I remember right. With IBM's third generation computers (S/360s) and probably other manufacturers, ECC became a standard feature. Parity checking was added through different data paths such as channel memory, buffer memory, etc. There was so much protection added that the programmed checksums became superfluous. There were still odd moments. I remember working on an Amdahl computer problem where some internal data paths... where the contents of one register moved to an internal storage area... and the path did not have parity. There was a machine fault... the path was electrically open, so the contents of the register always became zero. But since it wasn't parity checked, there was no machine check. I remember another problem on the IBM 3033. Cosmic rays (really) caused one bit errors in channel memory. That was parity but not ECC so you got a weird channel check. Back at the diagnosis ranch, the board looked good. It was only when someone noticed that the rate of such problems was proportional to the height above sea level that the light bulb went on. The lesson is that when paths are not checked, hardware or software, data being held or transformed can change. Old lesson but a good one to know. john alvord - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Wed, 11 Apr 2001 20:57:04 +0200, Jamie Lokier <[EMAIL PROTECTED]> wrote: >george anzinger wrote: >> > A pointer-based priority queue is really not a very complex thing, and >> > there are ways to optimise them for typical cases like the above. >> > >> Please do enlighten me. The big problem in my mind is that the >> pointers, pointing at points in time, are perishable. > >Um, I'm not sure what perishability has to do with anything. Timers at >the moment can be added, deleted and destroyed and it's no big deal. > >Look in an algorithms book under "priority queue". They usually don't >say how to use a heap-ordered tree -- usually it's an array -- but you >can use a tree if you want. In such a tree, each timer has a link to >_two_ next timers and one previous timer. (The previous timer link is >only needed if you can delete timers before they expire, which is >required for Linux). > >I'm not saying saying a heap-ordered tree is fastest. But it's ok, and >doesn't require any more storage than the `struct timer' objects >themselves. > >It's possible to optimise this kind of data structure rather a lot, >depending on how you want to use it. Linux' current timer algorithm is >a pretty good example of a priority queue optimised for timer ticks, >where you don't mind doing a small amount of work per tick. > >One notable complication with the kernel is that we don't want every >timer to run at its exactly allocated time, except for some special >timers. For example, if you have 100 TCP streams and their >retransmission times are scheduled for 1.s, 1.0001s, 1.0002s, etc., >you'd much rather just process them all at once as is done at the moment >by the 100Hz timer. This is because cache locality is much more >important for TCP retransmits than transmit timing resolution. > >There's literature online about this class of problems: look up "event >set" and "simulation" and "fast priority queue". I bumped into a funny non-optimization a few years ago. A system with a timer queue like the above had been "optimized" by keeping old timer elements... ready for new tasks to link onto and activate. The granularity was 1 millsecond. Over time, all timer values from 0 to roughly 10 minutes had been used. That resulted in 60,000 permanent storage fragments laying about... a significant fragmentation problem. The end was a forced recycle every month or so. john alvord - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Wed, 11 Apr 2001 20:57:04 +0200, Jamie Lokier [EMAIL PROTECTED] wrote: george anzinger wrote: A pointer-based priority queue is really not a very complex thing, and there are ways to optimise them for typical cases like the above. Please do enlighten me. The big problem in my mind is that the pointers, pointing at points in time, are perishable. Um, I'm not sure what perishability has to do with anything. Timers at the moment can be added, deleted and destroyed and it's no big deal. Look in an algorithms book under "priority queue". They usually don't say how to use a heap-ordered tree -- usually it's an array -- but you can use a tree if you want. In such a tree, each timer has a link to _two_ next timers and one previous timer. (The previous timer link is only needed if you can delete timers before they expire, which is required for Linux). I'm not saying saying a heap-ordered tree is fastest. But it's ok, and doesn't require any more storage than the `struct timer' objects themselves. It's possible to optimise this kind of data structure rather a lot, depending on how you want to use it. Linux' current timer algorithm is a pretty good example of a priority queue optimised for timer ticks, where you don't mind doing a small amount of work per tick. One notable complication with the kernel is that we don't want every timer to run at its exactly allocated time, except for some special timers. For example, if you have 100 TCP streams and their retransmission times are scheduled for 1.s, 1.0001s, 1.0002s, etc., you'd much rather just process them all at once as is done at the moment by the 100Hz timer. This is because cache locality is much more important for TCP retransmits than transmit timing resolution. There's literature online about this class of problems: look up "event set" and "simulation" and "fast priority queue". I bumped into a funny non-optimization a few years ago. A system with a timer queue like the above had been "optimized" by keeping old timer elements... ready for new tasks to link onto and activate. The granularity was 1 millsecond. Over time, all timer values from 0 to roughly 10 minutes had been used. That resulted in 60,000 permanent storage fragments laying about... a significant fragmentation problem. The end was a forced recycle every month or so. john alvord - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
On Sat, 03 Feb 2001 00:57:45 -0800, David Ford <[EMAIL PROTECTED]> wrote: >How about a simple patch to the top level makefile that checks the gcc >version then prints a distinct message ..'this compiler hasn't been approved >for compiling the kernel', sleeping for one second, then continuing on. This >solution doesn't stop compiling and makes a visible indicator without forcing >anything. A while ago I worked up a nasty bit of make logic which prompted the user for yes or no... and then did one thing or the other. You could ask the user if he REALLY wants to continue and wait for a response. Following is the model code... John Alvord = _ECHO=@ all: t0 t1 t2 t3 t4 t5 t6 # prompt for input, must be in a separate rule to unbuffer terminal # output. t0: $(_ECHO)echo Enter Y or N: \\c # capture a line of terminal input, copy to a file, tell user t1: $(_ECHO)echo $(shell read ans; echo ans) > ans $(_ECHO)echo The answer is \\c $(_ECHO)cat ans # take first character of answer, upper case, store in another file # then create two files, one for yes and one for no # the || exit 0 is to mask the potential grep error, which # would result in an error message even a - was used to ignore error # and continue. The result is two files, which may be zero byte t2: $(_ECHO)cat ans | cut -c 1-1 | tr 'a-z' 'A-Z' >ans1 $(_ECHO)rm -f ansy $(_ECHO)rm -f ansn $(_ECHO)grep Y ans1 > ansy || exit 0 $(_ECHO)grep N ans1 > ansn || exit 0 # Check for case where neither answer file is > 0 bytes t3: $(_ECHO)test -s ansy || test -s ansn && exit 0; \ echo Answer [$(shell cat ans)] is neither Y or N! && exit 1 # handle Yes case. Exit if Y answer file is 0 bytes or missing t4: $(_ECHO)test ! -s ansy && exit 0; \ echo in YES processing # handle No case t5: $(_ECHO)test ! -s ansn && exit 0; \ echo in NO processing # remove files used during processing t6: $(_ECHO)rm -f ans $(_ECHO)rm -f ans1 $(_ECHO)rm -f ansn $(_ECHO)rm -f ansy - 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-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
On Sat, 03 Feb 2001 00:57:45 -0800, David Ford [EMAIL PROTECTED] wrote: How about a simple patch to the top level makefile that checks the gcc version then prints a distinct message ..'this compiler hasn't been approved for compiling the kernel', sleeping for one second, then continuing on. This solution doesn't stop compiling and makes a visible indicator without forcing anything. A while ago I worked up a nasty bit of make logic which prompted the user for yes or no... and then did one thing or the other. You could ask the user if he REALLY wants to continue and wait for a response. Following is the model code... John Alvord = _ECHO=@ all: t0 t1 t2 t3 t4 t5 t6 # prompt for input, must be in a separate rule to unbuffer terminal # output. t0: $(_ECHO)echo Enter Y or N: \\c # capture a line of terminal input, copy to a file, tell user t1: $(_ECHO)echo $(shell read ans; echo ans) ans $(_ECHO)echo The answer is \\c $(_ECHO)cat ans # take first character of answer, upper case, store in another file # then create two files, one for yes and one for no # the || exit 0 is to mask the potential grep error, which # would result in an error message even a - was used to ignore error # and continue. The result is two files, which may be zero byte t2: $(_ECHO)cat ans | cut -c 1-1 | tr 'a-z' 'A-Z' ans1 $(_ECHO)rm -f ansy $(_ECHO)rm -f ansn $(_ECHO)grep Y ans1 ansy || exit 0 $(_ECHO)grep N ans1 ansn || exit 0 # Check for case where neither answer file is 0 bytes t3: $(_ECHO)test -s ansy || test -s ansn exit 0; \ echo Answer [$(shell cat ans)] is neither Y or N! exit 1 # handle Yes case. Exit if Y answer file is 0 bytes or missing t4: $(_ECHO)test ! -s ansy exit 0; \ echo in YES processing # handle No case t5: $(_ECHO)test ! -s ansn exit 0; \ echo in NO processing # remove files used during processing t6: $(_ECHO)rm -f ans $(_ECHO)rm -f ans1 $(_ECHO)rm -f ansn $(_ECHO)rm -f ansy - 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: [Fwd: NTFS repair tools]
On Sat, 09 Dec 2000 21:34:59 -0500, David Feuer <[EMAIL PROTECTED]> wrote: >At 08:12 PM 12/9/2000 -0600, Rene wrote: >>I think part of the problem is that there are other things labeled >>DANGEROUS that actually do work fairly reliably (offhand, I'm thinking >>off the IDE config stuff..). Perhaps it needs to explicitely say >>'This is broken and is gauranteed to destroy your data. Do not use it' >> >>The 'DANGEROUS' label seems to suggest that it -may- destroy data, which >>leads to the 'it won't happen to me' mentality. > >For what it's worth, I absolutely agree with this. I have the same >impression when I just see the word "dangerous". If this was a business, and we were knowingly distributing software that was known to be dangerous, we would probably be risking legal action. Why are we distributing such severely broken software? Heck, we seem reluctant to include reiserfs, a pretty high quality, supported file system. And we continue to distribute this !@#$%... There must be some strange agenda going on to limit the use of Linux. john alvord - 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: [Fwd: NTFS repair tools]
On Sat, 09 Dec 2000 21:34:59 -0500, David Feuer [EMAIL PROTECTED] wrote: At 08:12 PM 12/9/2000 -0600, Rene wrote: I think part of the problem is that there are other things labeled DANGEROUS that actually do work fairly reliably (offhand, I'm thinking off the IDE config stuff..). Perhaps it needs to explicitely say 'This is broken and is gauranteed to destroy your data. Do not use it' The 'DANGEROUS' label seems to suggest that it -may- destroy data, which leads to the 'it won't happen to me' mentality. For what it's worth, I absolutely agree with this. I have the same impression when I just see the word "dangerous". If this was a business, and we were knowingly distributing software that was known to be dangerous, we would probably be risking legal action. Why are we distributing such severely broken software? Heck, we seem reluctant to include reiserfs, a pretty high quality, supported file system. And we continue to distribute this !@#$%... There must be some strange agenda going on to limit the use of Linux. john alvord - 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: [PATCH] removal of "static foo = 0"
On Sun, 26 Nov 2000 04:25:05 + (GMT), Alan Cox <[EMAIL PROTECTED]> wrote: >> AB> of changes that yield a negligable advantage and reduce stability >> AB> a tiny little bit. That is pushing Linux in the direction of this >> AB> abyss. You notice that the view gets better, and I get nervous. >> >> Can somebody stop this train load of bunk? >> >> Uninitialized global variables always have a initial value of >> zero. Static or otherwise. Period. > >That isnt what Andries is arguing about. Read harder. Its semantic differences >rather than code differences. > > static int a=0; > >says 'I thought about this. I want it to start at zero. I've written it this >way to remind of the fact' > >Sure it generates the same code It also says "I do not know much about the details of the kernel C environment. In particular I do not know that all static variables are initialized to 0 in the kernel startup. I have not read setup.S." john alvord - 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: [PATCH] removal of static foo = 0
On Sun, 26 Nov 2000 04:25:05 + (GMT), Alan Cox [EMAIL PROTECTED] wrote: AB of changes that yield a negligable advantage and reduce stability AB a tiny little bit. That is pushing Linux in the direction of this AB abyss. You notice that the view gets better, and I get nervous. Can somebody stop this train load of bunk? Uninitialized global variables always have a initial value of zero. Static or otherwise. Period. That isnt what Andries is arguing about. Read harder. Its semantic differences rather than code differences. static int a=0; says 'I thought about this. I want it to start at zero. I've written it this way to remind of the fact' Sure it generates the same code It also says "I do not know much about the details of the kernel C environment. In particular I do not know that all static variables are initialized to 0 in the kernel startup. I have not read setup.S." john alvord - 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: test10-pre7
On Tue, 31 Oct 2000 05:59:59 -0600, Peter Samuelson <[EMAIL PROTECTED]> wrote: > >[Linus] >> In short, we should _remove_ all traces of stuff like >> >> O_OBJS = $(filter-out $(export-objs), $(obj-y)) >> >> It's wrong. >> >> We should just have >> >> O_OBJS = $(obj-y) >> >> which is always right. > >This part I agree with.. > >> And it should make all this FIRST/LAST object file mockery a total >> non-issue, because the whole concept turns out to be completely >> unnecessary. >> >> Is there anything that makes this more complex than what I've >> outlined above? > >One thing. The main benefit of $(sort), which I haven't heard you >address yet, is to remove duplicate files. Think about 8390.o, and how >many net drivers require it. There are two ways to handle this: > > obj-$(CONFIG_WD80x3) += wd.o 8390.o > obj-$(CONFIG_EL2) += 3c503.o 8390.o > obj-$(CONFIG_NE2000) += ne.o 8390.o > obj-$(CONFIG_NE2_MCA) += ne2.o 8390.o > obj-$(CONFIG_HPLAN) += hp.o 8390.o > You can avoid duplicates with obj-$(CONFIG_WD80x3) += wd.o ifneq (,$(findstring 8390.o,obj-$(CONFIG_WD80x3)) obj-$(CONFIG_WD80x3) += 8390.o endif Which is wordy but accomplishes the objective of avoiding duplicates. john alvord - 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: test10-pre7
On Tue, 31 Oct 2000 05:59:59 -0600, Peter Samuelson [EMAIL PROTECTED] wrote: [Linus] In short, we should _remove_ all traces of stuff like O_OBJS = $(filter-out $(export-objs), $(obj-y)) It's wrong. We should just have O_OBJS = $(obj-y) which is always right. This part I agree with.. And it should make all this FIRST/LAST object file mockery a total non-issue, because the whole concept turns out to be completely unnecessary. Is there anything that makes this more complex than what I've outlined above? One thing. The main benefit of $(sort), which I haven't heard you address yet, is to remove duplicate files. Think about 8390.o, and how many net drivers require it. There are two ways to handle this: obj-$(CONFIG_WD80x3) += wd.o 8390.o obj-$(CONFIG_EL2) += 3c503.o 8390.o obj-$(CONFIG_NE2000) += ne.o 8390.o obj-$(CONFIG_NE2_MCA) += ne2.o 8390.o obj-$(CONFIG_HPLAN) += hp.o 8390.o You can avoid duplicates with obj-$(CONFIG_WD80x3) += wd.o ifneq (,$(findstring 8390.o,obj-$(CONFIG_WD80x3)) obj-$(CONFIG_WD80x3) += 8390.o endif Which is wordy but accomplishes the objective of avoiding duplicates. john alvord - 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: Device Driver
On Mon, 16 Oct 2000 14:45:03 +0200 (CEST), Igmar Palsenberg <[EMAIL PROTECTED]> wrote: > >> >I presume your driver doesn't mind if this image is unavailable. >> >If not, you'll need to provide a open source image to use in place >> >of your proprietary one. >> >> Linus, please confirm. >> >> Firmware for cards can be proprietary. It can either be installed by a >> userspace utility on startup (nothing to do with the kernel) or it can >> be installed by the kernel driver for the card during initialization. >> In the latter case, the image must be supplied in text format and >> converted to binary, no binary files in the kernel tarball. > >Every closed source piece of software is unacceptable in a standard kernel >: > >-hh We can't debug it >- We depend on the guys / girls that maintain the binary image >- It's a security risk. > Aren't there other examples where firmware is supplied in a struct which is initialized to the needed binary values? Seems like Linux doesn't need every bit of source (probably for some completely other processor or ASIC, maybe written in FORTH) included as part of the kernel. johnh - 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: [OT] linux article with kernel references
On Wed, 11 Oct 2000 02:06:52 +0200 (MET DST), Roman Zippel <[EMAIL PROTECTED]> wrote: >Hi, > >On Wed, 11 Oct 2000, Alan Cox wrote: > >> > http://www.osopinion.com/Opinions/MontyManley/MontyManley15.html >> > >> > good article, several unfortunate truths within. >> >> Really, must be a wrong URL you posted then 8) >> >> The average Linux kernel hacker right now is late 20's to early 30's with >> a degree and working professionally on the kernel > >The article isn't that wrong, that several people get paid now for hacking >doesn't change much. It's more about proper software engineering, some >people call it "a matter of taste" and are born with it, but for other >people it's a hard learning process. The opinion piece is also (probably) about non-kernel software. It is hard to tell because he gives no examples at all. It was not pursuasive to me. I've seen terrible code on every system from IBM mainframes to Mac. That is not news. john - 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: [OT] linux article with kernel references
On Wed, 11 Oct 2000 02:06:52 +0200 (MET DST), Roman Zippel [EMAIL PROTECTED] wrote: Hi, On Wed, 11 Oct 2000, Alan Cox wrote: http://www.osopinion.com/Opinions/MontyManley/MontyManley15.html good article, several unfortunate truths within. Really, must be a wrong URL you posted then 8) The average Linux kernel hacker right now is late 20's to early 30's with a degree and working professionally on the kernel The article isn't that wrong, that several people get paid now for hacking doesn't change much. It's more about proper software engineering, some people call it "a matter of taste" and are born with it, but for other people it's a hard learning process. The opinion piece is also (probably) about non-kernel software. It is hard to tell because he gives no examples at all. It was not pursuasive to me. I've seen terrible code on every system from IBM mainframes to Mac. That is not news. john - 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: Tux 2 patents
On Thu, 5 Oct 2000 22:00:58 +, Alain Williams <[EMAIL PROTECTED]> wrote: >Hi, > >I remember when at the University of Cambridge (in England) about 25 years ago >seeing some work then about the Jackdaw (or was is Jackard) database system >that had the great feature of being immune to OS crashes, it used a phased >update mechanism where new blocks were written to disk and the last block >written was the one that contained the switched pointer, until this last block >had been written the changes had not been made. Since the write of a disk block >was atomic the database would never be corrupt. > >If someone wants I think that I still have a (paper) copy of the report describing >this. I can send/fax a copy if wanted. > >I don't subscribe to this list, so please reply direct if someone wants it. > >(Please don't request a copy just out of curiosity since I don't want to have >to post/fax copies that won't help resolve this case by showing prior art.) > >Cheers The VM/CMS operating system had a new file system around 1979 or 1980. It had exactly the same characteristics... writing the new blocks and then writing a final block which changed the world. The work was derived from Chris Stephens' work on YMS (Yorktown Monitor System). Since Chris was part of IBM Research, and since researchers got major brownie points from patents, I bet that the there are some patents to be found of interest. Clearly, the same idea has been rediscovered over and over again. The VM/CMS case would be a good example of prior art, since it had thousands of licenses and hundreds of thousands of end users in the early 1980s. john alvord - 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: Question: Using floating point in the kernel
On Wed, 20 Sep 2000 22:37:29 -0700, "Lyle Coder" <[EMAIL PROTECTED]> wrote: >Hi >The real issue is that if you use MMX or FP state, the kernel _must_ save >and restore the original state other wise user programs will see corruption. >We all know this too well since redhat's 6.1 (I think) kernel had this >optimized MMX functions that _screwed_ up user programs. The fact is... it >is tricky to save and restore state (device not available and all). >The basic kernel itself does not provide support for kernel code to use >these registers. If some device drivers or some modifications to the kernel >are using it.. then I hope they have the save/restore path right A 2.5-time problem is that portions of the kernel are planned to become interruptible... so saving and restoring around a certain usage would be insufficient. john - 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: Question: Using floating point in the kernel
On Wed, 20 Sep 2000 22:37:29 -0700, "Lyle Coder" [EMAIL PROTECTED] wrote: Hi The real issue is that if you use MMX or FP state, the kernel _must_ save and restore the original state other wise user programs will see corruption. We all know this too well since redhat's 6.1 (I think) kernel had this optimized MMX functions that _screwed_ up user programs. The fact is... it is tricky to save and restore state (device not available and all). The basic kernel itself does not provide support for kernel code to use these registers. If some device drivers or some modifications to the kernel are using it.. then I hope they have the save/restore path right A 2.5-time problem is that portions of the kernel are planned to become interruptible... so saving and restoring around a certain usage would be insufficient. john - 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
On Sun, 10 Sep 2000 00:23:43 -0700, "J. Dow" <[EMAIL PROTECTED]>
wrote:
>From: "Stephen E. Clark" <[EMAIL PROTECTED]>
>
>> Linus Torvalds wrote:
>> >
>> > On Sat, 9 Sep 2000, Oliver Xymoron wrote:
>> > >
>> > > Tools are tools. They don't make better code. They make better code easier
>> > > if used properly.
>> >
>> > I think you missed the point of my original reply completely.
>> >
>> > The _technical_ side of the tool in question is completely secondary.
>> >
>> > The social engineering side is very real, and immediate.
>> ...
>>
>> > Linus
>> >
>>
>> Then why don't we get rid of the compilers and assemblers and go back to
>> the old way of doing it
>> all - coding on the bare metal. Believe it or not at one time it was
>> done this way. Imagine where
>> we would be if everyone had said lets not invent tools to make ourselves
>> more productive.
>>
>> My $.02
>>
>> Steve Clark
>
>And for my severely depreciated $0.02 I am becoming concerned
>that these guys are more concerned about some macho ideal of
>generating programs while half crippled than about having things
>work properly and maintainably no matter what gets in the way.
>Art has flaws in it that have been painted over, often two or three
>times. I grew up with a giant painting of Beethoven along side the
>dinner table. It had been presented to my step-grandfather by
>the Leipzig Symphony Orchestra. It captured the brooding artist
>wonderfully. And in humid weather you could see his third hand,
>the one the artist didn't like and painted over.
>
>For all the zen meditation on code I begin to wonder how many of
>the fixes really are fixes or painted over features that didn't quite
>work out. It worries me no small bit.
>
> and here I thought macho didnt' fit well with people who
>used their brains. I see it is as alive and well here as on the
>streets of East LA.
>
>{O.O}
How can anyone judge that a debugger was used in development of a
patch, along with system understanding, Linux knowledge, etc? The
changed code stands along with no provenance. If it reflects a shallow
understanding, it will be rejected. If it is a deep elegant fix, that
will stand on its merits.
john alvord
-
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
On Sun, 10 Sep 2000 00:23:43 -0700, "J. Dow" [EMAIL PROTECTED]
wrote:
From: "Stephen E. Clark" [EMAIL PROTECTED]
Linus Torvalds wrote:
On Sat, 9 Sep 2000, Oliver Xymoron wrote:
Tools are tools. They don't make better code. They make better code easier
if used properly.
I think you missed the point of my original reply completely.
The _technical_ side of the tool in question is completely secondary.
The social engineering side is very real, and immediate.
...
Linus
Then why don't we get rid of the compilers and assemblers and go back to
the old way of doing it
all - coding on the bare metal. Believe it or not at one time it was
done this way. Imagine where
we would be if everyone had said lets not invent tools to make ourselves
more productive.
My $.02
Steve Clark
And for my severely depreciated $0.02 I am becoming concerned
that these guys are more concerned about some macho ideal of
generating programs while half crippled than about having things
work properly and maintainably no matter what gets in the way.
Art has flaws in it that have been painted over, often two or three
times. I grew up with a giant painting of Beethoven along side the
dinner table. It had been presented to my step-grandfather by
the Leipzig Symphony Orchestra. It captured the brooding artist
wonderfully. And in humid weather you could see his third hand,
the one the artist didn't like and painted over.
For all the zen meditation on code I begin to wonder how many of
the fixes really are fixes or painted over features that didn't quite
work out. It worries me no small bit.
sigh and here I thought macho didnt' fit well with people who
used their brains. I see it is as alive and well here as on the
streets of East LA.
{O.O}
How can anyone judge that a debugger was used in development of a
patch, along with system understanding, Linux knowledge, etc? The
changed code stands along with no provenance. If it reflects a shallow
understanding, it will be rejected. If it is a deep elegant fix, that
will stand on its merits.
john alvord
-
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/
