I just made a 2.5.1, but I'm still concentrating on bio stuff, so don't
bother sending me other patches unless they are serious bug-fixes to
something else.
2.5.1 is hopefully a good interim stage - many block drivers should work
fine, but many more do not. However, the pre-patches were getting
largish, so I'd rather do a 2.5.1 than wait for all the details.
As to other stuff - note the separation of drivers for new and old tulip
chips: if you have an old 2104x tulip chip (as opposed to the newer 2114x
chips) the regular tulip driver doesn't work any more for you. Don't be
surprised, select CONFIG_DE2104X.
Linus
-----
final:
- Al Viro: floppy_eject cleanup, mount cleanups
- Jens Axboe: bio updates
- Ingo Molnar: mempool fixes
- GOTO Masanori: Fix O_DIRECT error handling
pre11:
- Jeff Garzik: no longer support old cards in tulip driver
(see separate driver for old tulip chips)
- Pat Mochel: driverfs/device model documentation
- Ballabio Dario: update eata driver to new IO locking
- Ingo Molnar: raid resync with new bio structures (much more efficient)
and mempool_resize()
- Jens Axboe: bio queue locking
pre10:
- Jens Axboe: more bio stuff
- Ingo Molnar: mempool for bio
- Niibe Yutaka: Super-H update
pre9:
- Jeff Garzik: separate out handling of older tulip chips
- Jens Axboe: more bio stuff
- Anton Altaparmakov: NTFS 1.1.21 update
pre8:
- Greg KH: USB updates
- Jens Axboe: more bio updates
- Christoph Rohland: fix up proper shmat semantics
pre7:
- Jens Axboe: more bio fixes/cleanups/breakage ;)
- Al Viro: superblock cleanups, boot/root mounting.
pre6:
- Jens Axboe: more bio stuff
- Coda compile fixes
- Nathan Laredo: stradis driver update
pre5:
- Patrick Mochel: driver model infrastructure, part 1
- Jens Axboe: more bio fixes, cleanups
- Andrew Morton: release locking fixes
- Al Viro: superblock/mount handling
- Kai Germaschewski: AVM Fritz!Card ISDN driver
- Christoph Hellwig: make cramfs SMP-safe.
pre4:
- Jens Axboe: fix up bio highmem breakage, more cleanups
- Greg KH: USB update
pre3:
- Al Viro: more superblock cleanups
- Jens Axboe: more patches for new block IO layer
- Christoph Hellwig: get rid of the old, long- deprecated SCSI error
handling
pre2:
- Greg KH: USB update
- Richard Gooch: refcounting for devfs
- Jens Axboe: start of new block IO layer
pre1:
- me: README references to 2.4.x -> 2.5.x
- Alexander Viro: fix unmount inode breakage, show_vfsmnt cleanup
- Jeff Garzik: fix 8139too initialization
Linus Torvalds writes:
> 2.5.1 is hopefully a good interim stage - many block drivers should
> work fine, but many more do not. However, the pre-patches were
> getting largish, so I'd rather do a 2.5.1 than wait for all the
> details.
Trying a quick test-run here:
# modprobe ide-probe-mod
/lib/modules/2.5.1/kernel/drivers/ide/ide-mod.o: unresolved symbol block_ioctl
# modprobe ide-cd
/lib/modules/2.5.1/kernel/drivers/ide/ide-mod.o: unresolved symbol block_ioctl
# modprobe ide-disk
/lib/modules/2.5.1/kernel/drivers/ide/ide-mod.o: unresolved symbol block_ioctl
# modprobe nfs
/lib/modules/2.5.1/kernel/fs/nfs/nfs.o: unresolved symbol seq_escape
/lib/modules/2.5.1/kernel/fs/nfs/nfs.o: unresolved symbol seq_printf
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Sun, 16 Dec 2001, Richard Gooch wrote:
> # modprobe nfs
> /lib/modules/2.5.1/kernel/fs/nfs/nfs.o: unresolved symbol seq_escape
> /lib/modules/2.5.1/kernel/fs/nfs/nfs.o: unresolved symbol seq_printf
Fixed in the 2.4 forward port.
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
I have a patch for the nfs stuff. It's just a couple of EXPORT_SYMBOL lines
in the seq_file.c.
Craig.
On Sunday 16 December 2001 21:21, Richard Gooch wrote:
> Linus Torvalds writes:
> > 2.5.1 is hopefully a good interim stage - many block drivers should
> > work fine, but many more do not. However, the pre-patches were
> > getting largish, so I'd rather do a 2.5.1 than wait for all the
> > details.
>
> Trying a quick test-run here:
> # modprobe ide-probe-mod
> /lib/modules/2.5.1/kernel/drivers/ide/ide-mod.o: unresolved symbol
> block_ioctl
>
> # modprobe ide-cd
> /lib/modules/2.5.1/kernel/drivers/ide/ide-mod.o: unresolved symbol
> block_ioctl
>
> # modprobe ide-disk
> /lib/modules/2.5.1/kernel/drivers/ide/ide-mod.o: unresolved symbol
> block_ioctl
>
> # modprobe nfs
> /lib/modules/2.5.1/kernel/fs/nfs/nfs.o: unresolved symbol seq_escape
> /lib/modules/2.5.1/kernel/fs/nfs/nfs.o: unresolved symbol seq_printf
>
> Regards,
>
> Richard....
> Permanent: [email protected]
> Current: [email protected]
> -
> 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/
Linus,
As to be completely clear on your point, you do not want any patches that
describe the rules for driver "domain validation". Next, you do not want
any patches that fix gross things, too. IE, exiting of any ISR's to
perform BH events. Noting that one is not able to kludge it anymore, the
solution is to cut off the beast and start from scratch.
Now the significance of driver "domain validation", in block/storage is
the inner-play with the VM layer via a swap partition or file.
Until you can validate the new block io is correct at the data-transport
layer, where the requests are converted to the actual data-io to the disk
you have nothing but a WAG. You will also have no way to separate issues
of FS/Memory corruption should it not be gone yet. Otherwise you have to
disable any and all forms of SWAP real or file.
Since there is no way to validate the drivers and many believe it is
not important to perform such tests, how can you assure anyone given user
their data is safe? Right now you are giving the impression that you do
not care about data integrity, and refusing to acknowledge this will
further prove you are in the same camp.
I remember all the crap taken over FS Corruption in the past, and now
present to you a perfect driver and a way to authenticate the data
transport and you thumb down the idea, directly or indirectly. I had
plans to try and do the same for SCSI to become compliant to SPI 4, but
given the total rejection of layer isolateion for regression testing it
does not seem practical. This is stated because the simple case is being
rejected so I see no way to even present the more complex case ever.
So do us all the favor by answering and explaining your position on the
scale of this sensitive issue. I am sure everyone would like to hear your
views on the need or useless bloat that would result from having a
testable diskdrive data transport layer.
My bets are on you will call it "useless bloat".
Regards,
Andre Hedrick
CEO/President, LAD Storage Consulting Group
Linux ATA Development
Linux Disk Certification Project
On Sun, 16 Dec 2001, Linus Torvalds wrote:
>
> I just made a 2.5.1, but I'm still concentrating on bio stuff, so don't
> bother sending me other patches unless they are serious bug-fixes to
> something else.
>
> 2.5.1 is hopefully a good interim stage - many block drivers should work
> fine, but many more do not. However, the pre-patches were getting
> largish, so I'd rather do a 2.5.1 than wait for all the details.
>
> As to other stuff - note the separation of drivers for new and old tulip
> chips: if you have an old 2104x tulip chip (as opposed to the newer 2114x
> chips) the regular tulip driver doesn't work any more for you. Don't be
> surprised, select CONFIG_DE2104X.
>
> Linus
On Mon, Dec 17, 2001 at 11:11:23AM -0800, Andre Hedrick wrote:
>
> Linus,
>
> As to be completely clear on your point, you do not want any patches that
> describe the rules for driver "domain validation". Next, you do not want
> any patches that fix gross things, too. IE, exiting of any ISR's to
> perform BH events. Noting that one is not able to kludge it anymore, the
> solution is to cut off the beast and start from scratch.
>
> Now the significance of driver "domain validation", in block/storage is
> the inner-play with the VM layer via a swap partition or file.
>
> Until you can validate the new block io is correct at the data-transport
> layer, where the requests are converted to the actual data-io to the disk
> you have nothing but a WAG. You will also have no way to separate issues
> of FS/Memory corruption should it not be gone yet. Otherwise you have to
> disable any and all forms of SWAP real or file.
>
> Since there is no way to validate the drivers and many believe it is
> not important to perform such tests, how can you assure anyone given user
> their data is safe? Right now you are giving the impression that you do
> not care about data integrity, and refusing to acknowledge this will
> further prove you are in the same camp.
Translation: Andre has been in a few too many ATA meetings and can't think
without using storage industry insider-speak ;)
I only had a 6 months internship in storage, but I believe what he's
talking about are sound engineering principles.
The first of which is, if we are trying to find a problem in a complex
system, you try and isolate that system from influences of others. And if
you are trying to prevent new problems from showing up, you try and test
each component of a complex system as an ongoing process.
Andre is focusing on the block IO layer here, because that's his area of
expertise. I think he points out a symptom of a problem that needs to be
addressed for damn near every area of the kernel.
We REALLY need to have some sort of coherent strategy for testing
different components to determine whether they are worth putting in the
mainline kernel, and catch bugs sooner. Yes, given enough eyeballs, all
bugs are shallow, but given a little effort on setting up a an ongoing
test system, we can reduce the workload of the 'core' kernel people by not
having to have them sift through a bunch of useless bug reports because a
user didn't know what we all know about debugging.
We need to have some way of isolating different subsystems, and a catalog
of 'regression tests' to verify that new changes aren't causing subsystems
to fail. I don't expect regression tests to be able to catch every
possible mistake, but I *DO* expect that we should be able to catch every
mistake we have previously made. This way a core kernel person only has to
look debug a problem once, and write a test to catch it, instead of seeing
the same problem over, and over, and over again from 300 different users.
> I remember all the crap taken over FS Corruption in the past, and now
> present to you a perfect driver and a way to authenticate the data
> transport and you thumb down the idea, directly or indirectly. I had
> plans to try and do the same for SCSI to become compliant to SPI 4, but
> given the total rejection of layer isolateion for regression testing it
> does not seem practical. This is stated because the simple case is being
> rejected so I see no way to even present the more complex case ever.
>
> So do us all the favor by answering and explaining your position on the
> scale of this sensitive issue. I am sure everyone would like to hear your
> views on the need or useless bloat that would result from having a
> testable diskdrive data transport layer.
>
> My bets are on you will call it "useless bloat".
>
> Regards,
>
> Andre Hedrick
> CEO/President, LAD Storage Consulting Group
> Linux ATA Development
> Linux Disk Certification Project
>
> On Sun, 16 Dec 2001, Linus Torvalds wrote:
>
> >
> > I just made a 2.5.1, but I'm still concentrating on bio stuff, so don't
> > bother sending me other patches unless they are serious bug-fixes to
> > something else.
> >
> > 2.5.1 is hopefully a good interim stage - many block drivers should work
> > fine, but many more do not. However, the pre-patches were getting
> > largish, so I'd rather do a 2.5.1 than wait for all the details.
> >
> > As to other stuff - note the separation of drivers for new and old tulip
> > chips: if you have an old 2104x tulip chip (as opposed to the newer 2114x
> > chips) the regular tulip driver doesn't work any more for you. Don't be
> > surprised, select CONFIG_DE2104X.
> >
> > Linus
>
>
>
> -
> 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/
>
--
Troy Benjegerdes | master of mispeeling | 'da hozer' | [email protected]
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz
On Tue, 18 Dec 2001, Troy Benjegerdes wrote:
>
> Translation: Andre has been in a few too many ATA meetings and can't think
> without using storage industry insider-speak ;)
We know ;)
> I only had a 6 months internship in storage, but I believe what he's
> talking about are sound engineering principles.
No. Sound software engineering principles is to design good interfaces,
and make the low level code adhere to them.
Andre comes from the other end - he writes and talks about low-level code,
and thinks that should drive how upper layers work.
Linus
On Mon, Dec 17, 2001 at 10:12:21PM -0800, Linus Torvalds wrote:
>
> On Tue, 18 Dec 2001, Troy Benjegerdes wrote:
> >
> > Translation: Andre has been in a few too many ATA meetings and can't think
> > without using storage industry insider-speak ;)
>
> We know ;)
>
> > I only had a 6 months internship in storage, but I believe what he's
> > talking about are sound engineering principles.
>
> No. Sound software engineering principles is to design good interfaces,
> and make the low level code adhere to them.
Well, I may have mis-stated my intentions in the last email. What I want
to see is some mechanism and *code* to test these interfaces and verify
that the low (AND high) level code is actually adhering to the interface,
as well as attemp to isolate which side of an interface a failure has
occured on. I want fault isolation, and TESTING to make sure that any
fault we have seen in the past can be detected with easy-to run code.
--
Troy Benjegerdes | master of mispeeling | 'da hozer' | [email protected]
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz
On Mon, Dec 17, 2001 at 10:12:21PM -0800, Linus Torvalds wrote:
> No. Sound software engineering principles is to design good interfaces,
> and make the low level code adhere to them.
Last week, Linus Torvalds wrote:
> I _am_ claiming that the people who think you "design" software are
> seriously simplifying the issue, and don't actually realize how they
> themselves work.
So which is it?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Mon, 17 Dec 2001, Larry McVoy wrote:
> On Mon, Dec 17, 2001 at 10:12:21PM -0800, Linus Torvalds wrote:
> > No. Sound software engineering principles is to design good interfaces,
> > and make the low level code adhere to them.
>
> Last week, Linus Torvalds wrote:
> > I _am_ claiming that the people who think you "design" software are
> > seriously simplifying the issue, and don't actually realize how they
> > themselves work.
>
> So which is it?
It must be the latter, since Linus has always stated a
preference for simplifying issues. Oh wait, that one
is incompatible with both ;)
cheers,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/
http://www.surriel.com/ http://distro.conectiva.com/
On Mon, 17 Dec 2001, Linus Torvalds wrote:
> Andre comes from the other end - he writes and talks about low-level code,
> and thinks that should drive how upper layers work.
Now would you mind telling us how his suggestion to clearly separates
the layers led you to THIS conclusion? He's after testability in the
first place.
--
Matthias Andree
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin
Rik van Riel <[email protected]> writes:
> On Mon, 17 Dec 2001, Larry McVoy wrote:
> > On Mon, Dec 17, 2001 at 10:12:21PM -0800, Linus Torvalds wrote:
> > > No. Sound software engineering principles is to design good interfaces,
> > > and make the low level code adhere to them.
> >
> > Last week, Linus Torvalds wrote:
> > > I _am_ claiming that the people who think you "design" software are
> > > seriously simplifying the issue, and don't actually realize how they
> > > themselves work.
> >
> > So which is it?
>
> It must be the latter, since Linus has always stated a
> preference for simplifying issues. Oh wait, that one
> is incompatible with both ;)
it's a zen koan. or like in the old hitchhiker's guide game, where to
win you had to hold both tea and no tea at the same time.
ian
On Mon, 17 Dec 2001, Larry McVoy wrote:
>
> So which is it?
Can you go back, and _read_ the messages?
In particular, microscopic vs macroscopic.
Linus
On Tue, Dec 18, 2001 at 08:43:40AM -0800, Linus Torvalds wrote:
> > So which is it?
>
> Can you go back, and _read_ the messages?
I read them, I read them again, and I've read them a third time. If you
want, I'll put together a summary of your statements so that you can
read what you wrote again and think about it. You can wiggle all you
want, Linus, your statements were clear and you are trying to have it
both ways. But I doubt you'll admit it, nobody likes to look foolish,
so let's let it go.
What I would like is for you to make a clear statement about what you
think is a good way to approach systems problems. You've bounced from
"design is good" to "design is bad" and I don't want to nitpick, I want
to know what you think. After you've *thought* about it, as opposed to
just some kneejerk reaction for effect.
I'm not alone in this, either. Since you are the final decision maker
on what goes in, many people in the world would like to know how to do
things "correctly" from your point of view.
A thoughtful writeup on how to make something happen in the Linux kernel
would be well received.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm