Bob Tracy said:
The attached patch set implements a PCMCIA SCSI driver for host adapters based on the Symbios 53c500 chip. The original driver for this chip was written by Thomas Corner and available only as an add-on to the pcmcia-cs package. I've been maintaining the add-on driver on an infrequent basis for the past several years, and the release of the 2.6 kernel "forced" a long overdue update.
The only host adapter I'm aware of that uses the sym53c500 controller chip is the "new" version of the New Media Bus Toaster (circa 1996), and the attached driver has been tested using this particular adapter on a 2.6.4 kernel. The patch set applies cleanly to 2.6.4 and 2.6.5.
Christoph Hellwig replied:
I've given it a short spin and here's a bunch of comments:
- the split into three source files is supserflous, one file should do it
- please don't use host.h or scsi.h from drivers/scsi/. The defintions not present in include/scsi/ are deprecated and shall not be used (the most prominent example in your driver are the Scsi_<Foo> typedefs that have been replaced by struct scsi_foo
- the driver doesn't even try to deal with multiple HBAs
- your detection logic could be streamlined a little, e.g. the request/release resource mess
Regarding collecting everything into a single file, Bob was
skeptical. He said that currently it was true, the driver only supported
PCMCIA implementations, so there was no real need for multiple files. But
he added, My thinking was if someone comes up with a
host adapter that isn't PCMCIA, the SYM53C500.c file is to the sym53c500_cs
driver what the qlogicfas.c file is to the qlogic_cs driver, that is, core
functions that could support multiple types of host adapters.
Bill
Davidsen thought this made enough sense to justify the split, especially given
that Bob had split the files along the lines that other drivers had already
used; but Christoph said it would be better to wait until the need actually
arose before splitting the file. Otherwise the danger was that the split as
currently designed might not be quite right, and it tended to add unnecessary
complexity just by having more files than was actually necessary.
In response to Christoph's objection in his original post, to Bob's
detection logic, Bob said he'd try to clean it up, adding, the goal for the initial port was to replicate the functionality I
already had in older kernel versions. It appears I faithfully replicated
the deficiencies of the old driver as well :-).
Christoph explained,
Any 2.6 driver is better than none and your
looks quite okay from the functional standpoint. We just need to have a
little higher bars for new drivers as we already have lots of maintaince
overhead for old and sloppy written drivers.
Bob replied, Attached is the second attempt at a 2.6 PCMCIA driver for
SCSI cards based on the Symbios 53c500 controller. The patch set was tested
with (and applies cleanly to) 2.6.5. As requested, the driver source has
been consolidated into a single file. All remnants of code that might have
supported non-PCMCIA host adapters have been ripped out, which allowed for the
requested streamlining of the detection logic: Card Services is doing most
of the heavy lifting in that area anyway :-).
After some detailed
technical criticism by Christoph going line-by-line through the patch,
Bob posted a third update, saying:
here's the latest attempt at a 2.6 driver for PCMCIA SCSI cards using the Symbios 53c500 controller. This includes (at least) "newer" versions of the New Media Bus Toaster (circa 1997). The attached patch set applies cleanly to 2.6.5.
In addition to all the concerns Christoph raised in response to the previous two submissions, there was an issue with the code for handling a CS_EVENT_CARD_RESET event: the event handler was calling the bus_reset function with a NULL scsi_cmnd argument. The potential problem was masked by the fact my bus_reset function was a trivial reimplementation of the default behavior in the absence of a bus_reset function. Folks using the qlogic_cs driver are hereby warned: if the event handler tries to process a CS_EVENT_CARD_RESET event (probably following a "resume"), qlogicfas_bus_reset() will be called with a NULL scsi_cmnd argument, and the next thing you'll see will be the "oops" resulting from a null pointer dereference. For what it's worth, someone besides me has noted this can happen: see the comment block above qlogicfas_bus_reset() in linux/drivers/scsi/qlogicfas.c.
Major differences between this version and prior ones:
- Support for multiple HBAs should now be in place. The only global host variable affects the PIO speed, and that's affected by a compile- time define.
- Although proc_info is officially obsolete in 2.6, I didn't delete the associated code: it can be enabled by defining PROC_INFO at compile time (for people like me who find it useful).
- Cleanup/consolidation of multiple functions, including deletion of code rendered superfluous by new 2.6 ways of doing things.
Barring any remaining issues (Christoph?), I think we're finally ready for prime time :-).
Russell King had an objection to offer. He said:
what happens if you're in the middle of a transaction, and you receive a CS_EVENT_CARD_RESET. What happens to the command in progress ?
Sure, the hardware is reset to a sane state, but what about the software state in the driver?
Bob admitted he didn't know what would happen in that case; Russell
remarked, From the brief look I had, it didn't look
like it - I suspect things will go gaga if someone ever invoked "cardctl
reset".
Bob replied that maybe this was a case of just telling the
user to avoid doing that... but there was no further discussion.
Marcelo Tosatti, in addition to maintaining the 2.4 kernel, has also been doing a bit of 2.6 work as well. He submitted a patch to Andrew Morton, saying:
Here goes the signal pending & POSIX mqueue's per-uid limit patch.
Initialization has been moved to include/asm-i386/resource.h, as you suggested.
The global mqueue limit has been increased to 256 (64 per user), and the global signal pending limit to 4096 (1024 per user).
This has been well tested.
If you are OK with it for inclusion (-mm) I'll generate the arch-dependant changes for the other architectures.
Andrew approved the patch and encouraged Marcelo to do the
architecture-dependent code as well. Jakub Jelinek, close by, observed,
I wonder if it is a good idea to base mqueue
limitation on the number of message queues and not take into account how big
they are. 64 message queues with 1 byte msgsize and 1 maxmsg is certainly
quite harmless and the system could have even more queues for such a user,
while 64 message queues with 16K msgsize (current default) and 40 maxmsg
(also default) eats ~ 40M of kernel memory.
Marcelo agreed with this,
saying the the amount of memory actually used would be a better yardstick.
Manfred Spraul cautioned, I agree, but note that
there is one hidden problem: There can be one notification for each registered
message queue. If there are more than ~560 queues and one process wants to
install SIGEV_THREAD notification handlers for all of them, then the netfilter
code will run against the socket rmem limit and mq_notify will block. _If_
there are users that do that we'll have to bypass the normal sk_rmem_alloc
and add an mqueue specific limit.
Andrew put it a little differently,
saying to Marcelo:
But we still have the global mq and signal limits? These permit local denials of service attacks. See http://seclists.org/lists/linux-kernel/2004/Apr/2065.html
The major advantage of your work is that we can now remove those limits. You'll be needing a 2.4 backport ;)
Marcelo agreed with the DoS attack and the need for a 2.4 backport; though
he did add that actually it required 4 users acting in concert to successfully
do the attack. He also said, currently root is
allowed to allocate infinite number of mqueues. We want to remove that and
calculate on the amount of memory allocated. I'll also think about it and
come with an implementation.
Along with the kernel part of the port,
he also added, we also need to do the userspace
part. ulimit is part of bash, so probably all shell's should be awared of
this?
To that last, Andrew replied:
yup, the shells need to be changed, which is really awkward. I was wrong about how bash and zsh handle `ulimit 4 1024'.
Really the shells _should_ permit ulimit-by-number for this very reason.
Adding new ulimits is nice - it's a shame that the shells make it hard to use.
The next day Marcelo was hard at work again and posted a technical question; and a few posts later said:
Here goes the latest signal/mqueue per-uid limits patch. It now does:
- Create per-user signal limits, remove global limit
- Create per-user message queue limits, accounting is now done on memory-allocated (queue creation and message allocation). Note: it might be nice to move deaccounting inside free_msg().
I added an int to mqueue inode and to "struct msg_msg" (to save the UID of inode creator, to guarantee deaccounting is done correctly if another UID deletes the entries (eg root)). I wonder about cache locality. Has anyone cared enough to align the mqueue structures? Dont think so... Does it impact performance?
Thanks Andrew, Manfred and Jakub for their comments.
Attached are "mqsend.c" and "mqrec.c", two simple programs (copied from libmqueue) which I used for testing, in case anyone is interested.
Manfred had a technical criticism, but there was no discussion of this updated patch.
Clay Haapala said, This patch against 2.6.6-rc1-bk implements the CRC32C
algorithm as a type of digest. It is implemented as a wrapper for
libcrc32c, available in a separate patch. The crypto CRC32C module will
be used by the iscsi-sfnet driver.
David S. Miller and James Morris
approved of the patch; Clay rediffed the patches against the official 2.6.6-rc1
tree, and after clearing up a few small objections, David applied it.
Bartlomiej Zolnierkiewicz posted a patch to disable module unloading for
legacy IDE chipset drivers. This involved just removing the module_exit()
call from the drivers. Erik Andersen asked, Out
of curiosity, what would be needed to make it safe to unload all ide modules
from a system with a scsi rootfs?
Bartlomiej said that it made no
difference, because the user could regardless end up unloading modules that
were still in use. Erik Mouw said he'd been successfully unloading IDE
modules for years; he asked, What makes IDE
sufficiently different from SCSI that we can't unload IDE host
drivers?
Bartlomiej replied that a lack of reference counting, as
well as insufficient locking and other technical details accounted for this.
Erik M. asked, Do you plan to fix the module
unloading in the current code, or is it easier to write a new driver based
on libata (assuming it has been fixed in libata)? If I understood Jeff's
latest libata update correctly, it should be possible Real Soon Now [tm],
right?
Bartlomiej replied, I'm going to fix it but doing it properly requires major
changes in IDE code.
He added:
I think there is a common misunderstanding about libata: it will not replace IDE drivers any time soon.
I want to rewrite+merge current IDE code with libata during 2.7 (and yes, legacy naming and ordering will be preserved!).
I hope nobody starts rewriting existing IDE drivers for libata and pushing them upstream -> it will mean maintenance problems much bigger than OSS+ALSA.
However writing _new_ libata driver for 'exotic' PATA hardware is OK.
Marcelo Tosatti announced Linux 2.4.27-pre1, saying:
Most importantly it contains the addition of SATA drivers backport from v2.6.
Also network driver updates, USB updates, etc.
Geert Uytterhoeven posted a one-liner patch to the config scripts, saying that the Packet Generator (an experimental feature) wouldn't compile unless ProcFS was also included. David S. Miller accepted the patch gratefully, asking if 2.6 also needed a similar patch; but Geert confirmed that 2.6 already included the necessary dependencies.
Jeff Garzik said:
Attached is a patch, and the full 2.6.x version of the SiS driver, for testing.
This should address the problem where people were having their SATA drives not recognized at probe time.
Any feedback, including "you didn't break anything", would be great, as I don't have any SiS test hardware up and running.
Robin Parker gave it a whirl and said, What
can I say?? It worked like a charm.
Jeff Garzik said:
So, finally ATA has joined modern times. People familiar with ATA know the host controller interfaces have always been slow, often requiring 8+ io writes per command. The SCSI and ethernet controller folks have been rolling their eyes for years.
The current wave of SATA controllers make a big leap... into the present. Either DMA rings or queues of depths ~32 are becoming the norm. All very hotplug-friendly, with highly optimized fast paths.
Of course, as is the unfortunate norm in the storage industry, all of these are covered by NDAs, except for Intel's ICH6, which conforms the to the fully-open AHCI specification. In order to support such a controller, all you need are PCI ids, and the following specifications:
AHCI: http://www.intel.com/technology/serialata/pdf/rev1_0.pdf
SATA 1: http://www.serialata.org/collateral/zipdownloads/serialata10a.ZIP
SATA 2: http://www.serialata.org/collateral/pdf/S2Ext_1_1_Gold.pdf
ATA 1: http://www.t13.org/docs2004/d1532v1r4b ATA-ATAPI-7.pdf
ATA 2: http://www.t13.org/docs2004/d1532v1r4b ATA-ATAPI-7.pdf
ATA 3: http://www.t13.org/docs2004/d1532v1r4b ATA-ATAPI-7.pdfIn addition to being an open architecture, it has all the things you would expect of a modern controller: 64-bit DMA support everywhere (no bank switching), queueing support, trivial PIO and ATAPI support, access to the low-level SATA FIS, and more.
So kudos to the AHCI folks (mainly at Intel), for making a decent, open controller. I always prefer to work on drivers for decent hardware, whose hardware specification is open and public.
Sven Köhler replied, seems like SiS is going to use AHCI too: http://www.sis.com/products/chipsets/oa/athlon64/756Presentation.pdf
Andrew Morton announced 2.6.6-rc2-mm2, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6-rc2/2.6.6-rc2-mm2/
- Largeish reiserfs feature update. The biggest change is probably the new block allocation algorithm. See the changelog inside reiserfs-group-alloc-9.patch for details.
- Added the ia64 CPU hotplug support patch
- More work against the ext3 block allocator.
- Several more framebuffer driver update, some quite substantial.
- Lots of fixes, mostly minor.
Jon DeVree reported:
Someone needs to take a look at the MODULE_LICENSE string reported by the HSF modem drivers made by LinuxAnt.
http://www.linuxant.com/drivers/hsf/full/downloads.php
They creatively inserted a \0 character in it. MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only LICENSE file applies");
Runnning modinfo -F license on the compiled driver gives: GPL because of their creative null character. The actual license for most of the files is NOT GPL.
Chris Friesen remarked, Ewww...that's evil.
Maybe we need to store the size of the license string for modinfo, so it
doesn't stop at the first null?
Linus Torvalds announced 2.6.6-rc3, saying:
s390, cifs, ntfs, ppc, ppc64, cpufreq upates. Oh, and DVB and USB.
I'm hoping to do a final 2.6.6 later this week, so I'm hoping as many people as possible will test this.