4K stacks - again
Most of the technical issues have not changed since September, so those arguments will not be repeated here. It is worth noting that layered block devices and filesystems have mostly been fixed. In past kernels, highly stacked devices (think of a combination of RAID, encryption, and network filesystems) could end up with very long call chains in the kernel, and, as a result, overflow the kernel stack. Most of these calls have since been serialized, so block-layer stacking should not be a problem.
The issue that remains is NDISwrapper, the glue layer which allows Windows NDIS drivers to be loaded into a Linux kernel. Windows runs with a much larger kernel stack size, so NDIS driver writers have no reason to be as careful about stack usage. And, of course, these drivers cannot be fixed to work properly with Linux. Some have argued that breaking NDISwrapper is not a possibility, since many users rely upon it to make their wireless network adapters work. But patience with this line of thought is running thin, as can be seen in this outburst from Dave Jones:
The good news is that the wireless situation is not as bad as one might think. There is documentation for Broadcom chips available now, and a Broadcom driver is in the works. There is also an Atheros driver which is "nearly done." Once these drivers are complete and joined with the Intel drivers already in the mainline, Linux will have much better support for wireless devices, and far fewer systems will have any reason to use NDISwrapper.
There are a number of reasons for going with the 4K stack mode, including
better performance and higher reliability. Some distributions (e.g. Fedora
Core and RHEL) have been shipping 4K kernels for a while now. So, while
nobody has committed to moving the mainline (or -mm) toward 4K-only yet,
chances are improving that it will happen sometime in the not-too-distant
future.
| Index entries for this article | |
|---|---|
| Kernel | Kernel stack |
| Kernel | NDISwrapper |
Posted Nov 17, 2005 6:41 UTC (Thu)
by rfunk (subscriber, #4054)
[Link] (2 responses)
Posted Nov 17, 2005 13:00 UTC (Thu)
by gravious (guest, #7662)
[Link] (1 responses)
Posted Nov 18, 2005 14:35 UTC (Fri)
by gravious (guest, #7662)
[Link]
Posted Nov 17, 2005 8:12 UTC (Thu)
by JoeF (guest, #4486)
[Link]
Posted Nov 17, 2005 10:24 UTC (Thu)
by lacostej (guest, #2760)
[Link] (1 responses)
Posted Nov 18, 2005 7:03 UTC (Fri)
by Ross (guest, #4065)
[Link]
Posted Nov 17, 2005 14:16 UTC (Thu)
by rjw (guest, #10415)
[Link]
Posted Nov 17, 2005 14:22 UTC (Thu)
by mcatkins (guest, #4270)
[Link]
Wouldn't it be possible to move NDISwrapper into user space?
TAP, or somesuch, could shim the network device access. Getting
Of course, in userspace stack size is not much of an issue...
Martin
Posted Nov 17, 2005 15:26 UTC (Thu)
by elicriffield (guest, #33738)
[Link] (2 responses)
So NDISwrapper doesn't work with fedora core or RHEL? I don't use either so i don't know but that seems odd...
Posted Nov 17, 2005 15:56 UTC (Thu)
by fenrus (guest, #31654)
[Link]
not all the world is using ndiswrapper.. some people still have systems where they can use open source drivers...
Posted Nov 17, 2005 21:47 UTC (Thu)
by iabervon (subscriber, #722)
[Link]
Posted Nov 17, 2005 15:33 UTC (Thu)
by snitm (guest, #4031)
[Link] (1 responses)
Posted Nov 17, 2005 15:46 UTC (Thu)
by fenrus (guest, #31654)
[Link]
XFS -> function -> dm layer -> function -> dm layer -> function -> raid layer -> function -> scsi layer -> driver
(well theoretical example but you get the idea I hope)
in the new situation, instead of calling the function again, you return "do again" so it goes like
XFS -> function -> dm layer -|
so the max depth is 4 (well real world is slightly more complex) independent on how often you layer this. In the old situation you could layer a lot and go really big (11 in the example, but just layer more and it goes higher)
Posted Nov 20, 2005 15:37 UTC (Sun)
by zooko (guest, #2589)
[Link]
Posted Nov 29, 2005 17:31 UTC (Tue)
by dwheeler (guest, #1216)
[Link]
I'm just looking forward to rt2500 support getting into the mainline wireless drivers
kernel. It's one of the few 54mb chipsets that has had a GPL driver (and
the OpenBSD crowd, sticklers for hardware openness, recommends those
cards), but so far it has to be added separately.
Hey, if a Broadcom driver is coming, that would have some positive
implications for Linksys WRT54G boxes. But I get no such host when
trying to link to http://bcm43xx.berlios.de/.
I second that.wireless drivers
I have a d-link dwl-g122 (h/w ver. b1) 802.11g usb thingy which uses one of those ralink rt2500 chip things and it would be sweet if this got into the mainline kernel - especially before Dapper is released. The source is here serialmonkey. Hope this helps somebody.
regards,
Anto
Aha,wireless drivers
To reply to myself. I just checked... The rt2500usb driver is in 2.6.15 in Dapper. I don't know when this went in, odd, I've been following the announcements quite closely. I tried it out and didn't get it working so it's back to 2.6.12 and ndiswrapper for now. Maybe somebody more masochistic and not with exam deadlines looming might give it a go. (Am I the only person who hates iwconfig? It is terse to the point of mute. I've also got that dropped connection problem using dhcp over wireless that people are complaining about with Fedora, SUSE, Ubuntu and elsewhere. It is a pain.)
regards,
Anto
I am looking forward to a fully opensource Atheros driver in the kernel. I'm currently using the madwifi driver, which unfortunately has a closed part (better than nothing...)Atheros driver
There are still some questions on how the atheros driver was generated.4K stacks - again
Not using a clean reverse engineering process it seems.
But that was about the old Atheros driver which is distributed out-of-kernel, right? Or is that about the new driver... or are they in fact the same other than the firmware?4K stacks - again
Couldn't the NDIS wrapper be run in userspace anyway? 4K stacks - again
I don't know much about this but...:NDISwrapper - in user space?
access to the hardware would be the tricky part, although it should
be fairly easy for USB dongles, and various mapping tricks
might work for 'normal' devices.
>Some distributions (e.g. Fedora Core and RHEL) have been shipping 4K stacks - again
>4K kernels for a while now
sounds right yes4K stacks - again
NDISwrapper has no problem with 4K stacks. The problem is that the drivers it wraps can expect up to a 12K stack. Of course, Linux has never provided more than an 8K stack, so a given driver wouldn't necessarily work, but a number of popular drivers don't run out of stack even with only 4K.4K stacks - again
Could someone elaborate on what it means to 'serialize' the historically long call chains associated with block devices + lvm2 + nfs + firewall, etc?Most of these calls have since been serialized?
it goes like this; there is a key function that is used to submit IOMost of these calls have since been serialized?
and DM and co need to change the IO a bit and then cause it to be submitted again
function -> dm layer -|
function -> raid layer -|
function -> scsi layer -> driver
I use prism54 cards. The driver is GPLed (not counting
proprietary firmware). It Just Works if you install Ubuntu. On the down side, you have to very
carefully search to find a card which has a prism54 chipset. In fact, they might not be available any
more. Also, I had persistent problems with performance at long range. My Mac Airport Extreme
would buzz along just fine in that situation, but the prism54 system would stop working every
minute or so.
prism54
The FSF has information about hardware with FLOSS drivers.
Here's the FSF information on wireless cards.
After looking around, I bought a Ralink RT2500-based card,
an Asus WL-107G, for my lapttop -- it only cost $30, it supports b and g,
and Ralink gives excellent support for FLOSS. There is active work to improve the driver further, too.
No doubt there are others, but basing your purchasing decision on "what is supported" is usually a good plan when you can do it!
FSF hardware info