Adrian Bunk said:
This patch removes support for gcc < 3.2 .
The advantages are:
- reducing the number of supported gcc versions from 8 to 4 (support removed: 2.95, 2.96, 3.0, 3.1; still supported: 3.2, 3.3, 3.4, 4.0) allows the removal of several #ifdef's and workarounds
- my impression is that the older compilers are only rarely used, so miscompilations of a driver with an old gcc might not be detected for a longer amount of time
My personal opinion about the time and space a compilation requires is that this is no longer that much of a problem for modern hardware, and in the worst case you can compile the kernels for older machines on more recent machines.
This patch does not yet remove all the #ifdef's and other things that are now no longer required, it only let's the compilation #error for older gcc versions and updates the documentation.
I'd like to see this patch in the next -mm, and if noone will tell a strong reason for keeping support for these gcc versions I'll send the cleanups that are now.
David S. Miller replied:
Many people still use 2.95 because it's still the fastest way to get a kernel build done and that's important for many people.
And with 4.0 being a scary regression in the compile time performance area compared to 3.4, this becomes even more important to keep around.
Nigel Cunningham also wanted 2.95 support. And Bill Davidsen said,
I don't mean to offend anyone, but it seems that
the gcc project, at least WRT x86, has lost its way a bit. The compiler
is getting slower, and the generated code is not getting correspondingly
faster. Or smaller. I'm not sure about more correct... Keeping 2.95 might
not be a bad idea.
Elsewhere, Kurt Wall also said, Environments that require kernel compilation, often multiple times,
testing, benefit from shorter compile times. It can be the difference
between, say, completing a test suite overnight instead of having to wait
until tomorrow afternoon. Keeping 2.95, at least, has some value in such
environments.
Willy Tarreau added, I *do*
still use 2.95 a lot, and I'm not alone, judging from people around me. 2.95
has been the reference for a very long time, that's why it's still so much
present. 3.0 and 3.1 (even 3.2) have been there for a very short time frame,
but 2.95 and 3.3 really seem to be references compilers. So please keep
support for 2.95.
Miles Bader also thought Adrian's patch was a
bad idea. Gustavo Guillermo Perez also said, Please keep the 2.95 support I use to use a lot, on not new hardware.
If you have old hardware with not much resources gcc 2.95 works just fine
and fast, even you build the main kernel on other machine, by compatibility
issues one or two drivers should be builded a lot of times into the older
hardware, then we are forced to build gcc 3.4 or something like.
There was no conclusion during the thread, but with such a vocal outcry, it's doubtful a patch like Adrian's will be accepted in the near to middle term.
Linus Torvalds announced Linux 2.6.13-rc5, saying:
Ok, one more in the series towards final 2.6.13.
This one is small enough that both shortlog and diffstat fit comfortably: no big architecture updates or anything like that. Some input, x86-64 and ppc updates, and various fairly small fixes in random places.
Some reverts back to 2.6.12 behaviour - you've seen the discussions, and I'm sure we'll end up discussing things further for a long while still, but the plan is to release 2.6.13 with known behaviour characteristics.
Give it a good testing, I'm hoping this can really turn into 2.6.13.
Michael Thonke asked, what the plans/timeplan to
implement NCQ support for NVidia NForce4(CK804) SATAII based chipsets? Fact
is that is it possible to use NCQ with NForce4 SATAII on Windows system,
I wonder why it isn't support by libata?
Jeff Garzik replied, Ask NVIDIA. They are the only company that gives me -zero-
information on their SATA controllers. As such, there are -zero- plans for
NCQ on NVIDIA controllers at this time.
Elsewhere, Allen Martin
from NVidia said, Likely the only way nForce4
NCQ support could be added under Linux would be with a closed source binary
driver, and no one really wants that, especially for storage / boot volume.
We decided it wasn't worth the headache of a binary driver for this one
feature. Future nForce chipsets will have a redesigned SATA controller where
we can be more open about documenting it.
Some posts down the line,
Lee Revell remarked, Nvidia is not Linux friendly.
Their business is making hardware so people can play games on Windows.
Anything that their lawyers think might have a 0.0001% chance of interfering
with that business model in the slightest bit will not happen.
Elsewhere, Chris Wedgwood recommended, keeping
constant pressure of vendors like nvidia about openness is probably the best
we can do right now (obviously this means avoiding buying their products as
much as possible).
Alan Stern said:
This patch (as536) simplifies the driver-model core by replacing the klist used to store the set of devices bound to a driver with a regular list protected by a mutex. It turns out that even with a klist, there are too many opportunities for races for the list to be used safely by more than one thread at a time. And given that only one thread uses the list at any moment, there's no need to add all the extra overhead of making it a klist.
This version of the patch addresses the concerns raised earlier by Pat: the list and mutex have been given more succinct names, and the obscure special-case code in device_attach has been replaced with a FIXME comment. Note that the new iterators in driver.c could easily be changed to use list_for_each_entry_safe and list_for_each_entry, if the functions didn't offer the feature of starting in the middle of the list. If no callers use that feature, it should be removed.
I still think the APIs for device_bind_driver and device_release_driver need to be changed, because they each rely on dev->drv not changing at a time when no protecting locks are held. They will have to be fixed up in a later patch.
Greg KH said that avoiding races and simplifying the code was the reason
klists were introduced in the first place, and Christoph Hellwig remarked,
And shows once more that the klist approach
was totally misguided.
Alan avoided the debate, but did remark, Do note
that the bus's list of devices and the bus's list of registered drivers are
still klists. Only the driver's list of bound devices gets reverted to a
normal list.
Dmitry Torokhov proposed an exploit, saying, what do I do in the following scenario - I have a serio port
(AUX) that has a synaptics touchpad bound to it which is driven by psmouse
driver. psmouse driver registers a child port (synaptics pass-through) during
probe call. The child port is also driven by psmouse module - but it looks
like it will deadlock when binding. Am I missing something here?
Alan
confessed, I hate to say this, but you are right.
Can you suggest a way around this problem? Perhaps arranging things so
that the devlist_mutex is held only during the actual __device_bind_driver
call and not during probe... But there are so many tricky interactions and
possible races that this requires a lot of thought.
Over the next
day he did think about it, and then said:
Dmitry's point is well founded. Greg, I want to retract that klist patch (as536). I'll send in a revised version before long.
It looks like the best approach will simply be to eliminate the driver's list of bound devices altogether. That should make Christoph happy -- no klist, no list, no nothing! :-) The list hardly ever gets used, mainly when the driver is unloaded. We can already get the same effect by iterating over the bus's list of devices and skipping everything not bound to the driver.
This will eliminate a whole set of races and make the code more transparent (I hope).
Several days later, he said:
This is a revised version of the patch I sent in last week -- not yet a submission, more of an RFC. It turns out that removing the driver's list of bound devices isn't practical, because there are times when a device not yet on the bus's overall klist will be bound (this happens whenever a new device is registered, for instance).
Anyway, in this new version the locking is greatly simplified and the requirements are made much more explicit in the comments. This code will not be subject to deadlock when a driver's probe routine registers a child device that uses the same driver, or when a remove routine unregisters a child device from the same driver. I think this version is okay, but please look it over and see if anything looks amiss.
The next step will be to clean up the races inherent in device_bind_driver and device_release_driver. There are two obvious approaches:
Pass the driver as an argument rather than trusting the value stored in dev->driver.
Require the caller to lock dev->sem.
On the face of it, neither is particularly more attractive than the other. However, reading through the various places that call these routines (for example, drivers/input/serio/serio.c or drivers/pnp/card.c) revealed a pattern. In most cases, the callers of device_bind_driver _really_ want something that functions more like driver_probe_device but without the matching step. The callers are invoking the probe methods by hand rather than relying on the driver core to do so. There's maybe only one place where a caller actually does want the device bound to the driver without doing a probe.
This suggests it might be a good idea to split driver_probe_device into two pieces, one for matching and one for probing & binding. The second piece could then be used instead of device_bind_driver.
Another thing became apparent as well. All of the places that use these routines currently rely on the bus subsystem's rwsem for synchronization. Obviously this is bad, because that rwsem is on its way out. I don't know enough about all those different drivers to be able to tell whether they lock the rwsem merely because the old API required it or because they really do need some mutual exclusion. Still, this suggests that it might be best to require the callers to lock dev->sem -- i.e., use dev->sem sort of as a replacement for the bus rwsem.
Henrik Brix Andersen said, Here's
a patch for unifying the watchdog device node name to /dev/watchdog as
expected by most user-space applications.
Linus Torvalds apparently
liked the patch, but replied, Doesn't seem to be
serious enough to be worth it at this late stage in the 2.6.13 game. Can you
re-send after I do a release?
Henrik agreed. Olaf Hering remarked,
A patch like that is sitting in -mm since almost
5 months. I wonder why it was never merged,
but there was no reply.
Chris Wright said:
We (the -stable team) are announcing the release of the 2.6.12.5 kernel.
The diffstat and short summary of the fixes are below.
I'll also be replying to this message with a copy of the patch between 2.6.12.4 and 2.6.12.5, as it is small enough to do so.
The updated 2.6.12.y git tree can be found at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/
Wim Van Sebroeck said, I (finaly)
converted the watchdog-mm bitkeeper tree to a git repository:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog-mm.git
.