I'd like to propose we allow adding new device IDs as part
of the -stable process, but only under certain conditions:
1) Each device (or group of devices) gets added as a separate
patch, i.e. we don't just diff the device tables. This way
each original patch that added the device(s) upstream will
be become a single patch for -stable.
2) Devices that require new features/capabilities in their
driver won't be added.
Candidate patches would be something like these, which together
add support for the ATI SB700 ATA controller:
1)
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=823777181b4c0200923dcb026efa5b37f55c0ecf
Adds ATI sb700 quirk, using exactly the same one as sb600.
2)
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2bcfdde6767f2f07891d2753c25220012fe5e6d2
Adds the new device to the existing driver's device ID table.
On Tue, May 22, 2007 at 02:14:44PM -0400, Chuck Ebbert wrote:
> I'd like to propose we allow adding new device IDs as part
> of the -stable process, but only under certain conditions:
Who would be the primary benifactor of this?
The very large majority of users out there use a distro kernel, and they
provide the ids whenever possible as patches to their kernels, _or_ as a
config option at startup that adds the ids to the drivers through sysfs.
> 1) Each device (or group of devices) gets added as a separate
> patch, i.e. we don't just diff the device tables. This way
> each original patch that added the device(s) upstream will
> be become a single patch for -stable.
>
> 2) Devices that require new features/capabilities in their
> driver won't be added.
What's wrong with the current sysfs way of adding new device ids without
touching the kernel? Devices described above was the very reason we
added that functionality, so users would not have to constantly update
their kernel. The distros provide userspace tools that enable these ids
to be added and at boot time, everything "just works" properly.
So, because of that, I don't really see a need to be adding new device
ids to the -stable tree.
> Candidate patches would be something like these, which together
> add support for the ATI SB700 ATA controller:
>
> 1)
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=823777181b4c0200923dcb026efa5b37f55c0ecf
>
> Adds ATI sb700 quirk, using exactly the same one as sb600.
That's a quirk addition, not a new device id following the above
mentioned rules you set out :)
thanks,
greg k-h
On Tue, May 22, 2007 at 11:47:33AM -0700, Greg Kroah-Hartman wrote:
> On Tue, May 22, 2007 at 02:14:44PM -0400, Chuck Ebbert wrote:
> > I'd like to propose we allow adding new device IDs as part
> > of the -stable process, but only under certain conditions:
>
> Who would be the primary benifactor of this?
>
> The very large majority of users out there use a distro kernel, and they
> provide the ids whenever possible as patches to their kernels, _or_ as a
> config option at startup that adds the ids to the drivers through sysfs.
It does mean however that there's lots of duplicated work between
distros as everyone adds these patches anyway.
> What's wrong with the current sysfs way of adding new device ids without
> touching the kernel?
sure, that works in some cases, but for others (quirks etc) it obviously doesn't.
> > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=823777181b4c0200923dcb026efa5b37f55c0ecf
> >
> > Adds ATI sb700 quirk, using exactly the same one as sb600.
>
> That's a quirk addition, not a new device id following the above
> mentioned rules you set out :)
Right, but adding the quirk alone would be pointless with the ID.
This is a case where 'use sysfs' doesn't work.
Dave
--
http://www.codemonkey.org.uk
Greg KH wrote:
> What's wrong with the current sysfs way of adding new device ids without
> touching the kernel? Devices described above was the very reason we
> added that functionality, so users would not have to constantly update
> their kernel. The distros provide userspace tools that enable these ids
> to be added and at boot time, everything "just works" properly.
I haven't found a single distro that (a) makes it trivial to add PCI IDs
at install time, and then (b) ensures those PCI IDs remain persistent
for each boot. We are not at all to the "just works" stage yet.
> So, because of that, I don't really see a need to be adding new device
> ids to the -stable tree.
Maybe you are just not seeing all the developers that keep bringing this
up??
Really, it is just silly to think that one-line PCI IDs patches will
cause any harm at all, and it should be self-evident that there is clear
potential to HELP Linux users. That's why we're all here, right?
Jeff
On Tue, May 22, 2007 at 02:53:53PM -0400, Dave Jones wrote:
> On Tue, May 22, 2007 at 11:47:33AM -0700, Greg Kroah-Hartman wrote:
> > On Tue, May 22, 2007 at 02:14:44PM -0400, Chuck Ebbert wrote:
> > > I'd like to propose we allow adding new device IDs as part
> > > of the -stable process, but only under certain conditions:
> >
> > Who would be the primary benifactor of this?
> >
> > The very large majority of users out there use a distro kernel, and they
> > provide the ids whenever possible as patches to their kernels, _or_ as a
> > config option at startup that adds the ids to the drivers through sysfs.
>
> It does mean however that there's lots of duplicated work between
> distros as everyone adds these patches anyway.
But distros don't all standardize on the same -stable release anyway, so
I don't see how a large ammount of duplicated work happens here.
> > What's wrong with the current sysfs way of adding new device ids without
> > touching the kernel?
>
> sure, that works in some cases, but for others (quirks etc) it obviously doesn't.
I totally agree, and have never objected to quirk additions in the past.
thanks,
greg k-h
On Tue, May 22, 2007 at 03:04:08PM -0400, Jeff Garzik wrote:
> Greg KH wrote:
> > What's wrong with the current sysfs way of adding new device ids without
> > touching the kernel? Devices described above was the very reason we
> > added that functionality, so users would not have to constantly update
> > their kernel. The distros provide userspace tools that enable these ids
> > to be added and at boot time, everything "just works" properly.
>
> I haven't found a single distro that (a) makes it trivial to add PCI IDs at
> install time, and then (b) ensures those PCI IDs remain persistent for each
> boot. We are not at all to the "just works" stage yet.
Well, SuSE handles this just fine, but I do notice that RHEL 5 disables
the new_id stuff entirely, so I can see why you might get this
impression :)
> > So, because of that, I don't really see a need to be adding new device
> > ids to the -stable tree.
>
> Maybe you are just not seeing all the developers that keep bringing this
> up??
This is the second time it has occurred that I know of.
> Really, it is just silly to think that one-line PCI IDs patches will cause
> any harm at all, and it should be self-evident that there is clear potential
> to HELP Linux users. That's why we're all here, right?
I'm not disagreeing that it will help a set of users, or that it will
cause any harm at all. It's just currently outside the scope for what
we defined -stable as, and it will slightly increase the workload that
Chris and I have in keeping up with these patches.
So, if there is an overwhelming majority of people that strongly feel
that this is a good thing, fine, we can try it out.
I'm just trying to point out that the new_id sysfs stuff is there
explicitly for this very reason, as people were demanding that (Dell
being the major company behind it.)
thanks,
greg k-h
On Tue, May 22, 2007 at 12:35:38PM -0700, Greg Kroah-Hartman wrote:
> On Tue, May 22, 2007 at 03:04:08PM -0400, Jeff Garzik wrote:
> > Greg KH wrote:
> > > What's wrong with the current sysfs way of adding new device ids without
> > > touching the kernel? Devices described above was the very reason we
> > > added that functionality, so users would not have to constantly update
> > > their kernel. The distros provide userspace tools that enable these ids
> > > to be added and at boot time, everything "just works" properly.
> >
> > I haven't found a single distro that (a) makes it trivial to add PCI IDs at
> > install time, and then (b) ensures those PCI IDs remain persistent for each
> > boot. We are not at all to the "just works" stage yet.
>
> Well, SuSE handles this just fine, but I do notice that RHEL 5 disables
> the new_id stuff entirely, so I can see why you might get this
> impression :)
That's news to me. I didn't even realise it was possible to disable this.
Pointer?
> I'm just trying to point out that the new_id sysfs stuff is there
> explicitly for this very reason, as people were demanding that (Dell
> being the major company behind it.)
Theres more to this than just PCI IDs though.
ac97 ID updates, usb id updates, etc, etc.
We have many different forms of what are fundamentally, the same thing.
Dave
--
http://www.codemonkey.org.uk
Greg KH wrote:
> Well, SuSE handles this just fine, but I do notice that RHEL 5 disables
> the new_id stuff entirely, so I can see why you might get this
> impression :)
I looked at distros other than those produced by my employer.
Apparently you did not.
This is not how we best serve Linux users.
Jeff
* Greg KH ([email protected]) wrote:
> On Tue, May 22, 2007 at 03:04:08PM -0400, Jeff Garzik wrote:
> > Really, it is just silly to think that one-line PCI IDs patches will cause
> > any harm at all, and it should be self-evident that there is clear potential
> > to HELP Linux users. That's why we're all here, right?
Yes, we're here to help. The only compelling reasons not do to it were/are:
1) -stable has never been about adding features (easy to consider new
hardware support a feature).
2) In theory new hardware can seem to work with a simple PCI ID
update, and later we find it needs extra quirk handling or specific
driver support. This could mean adding buggy support for new hardware
to -stable. In practice, hopefully this isn't a real issue.
3) It hasn't been a pressing issue brought to our attention until this
thread and its predecessor earlier in the month.
My own personal experience is each time I've needed a PCI ID update for
new hardware it's also needed changes to the driver (read: e1000, every
single time). So from my perspective neither sysfs nor relaxing -stable
rules slightly would actually help provide support for new hardware,
but that's clearly limited experience.
> I'm not disagreeing that it will help a set of users, or that it will
> cause any harm at all. It's just currently outside the scope for what
> we defined -stable as, and it will slightly increase the workload that
> Chris and I have in keeping up with these patches.
>
> So, if there is an overwhelming majority of people that strongly feel
> that this is a good thing, fine, we can try it out.
Yes, if it will serve -stable users better, we can give it a trial run
to see how it goes.
thanks,
-chris
On Tue, May 22, 2007 at 04:24:04PM -0400, Jeff Garzik wrote:
> Greg KH wrote:
> > Well, SuSE handles this just fine, but I do notice that RHEL 5 disables
> > the new_id stuff entirely, so I can see why you might get this
> > impression :)
>
> I looked at distros other than those produced by my employer.
>
> Apparently you did not.
>
> This is not how we best serve Linux users.
See that ":)" above?
Anyway, I'm pretty sure that Ubuntu also handles new device ids through
sysfs, or so I was told once, but I don't have a box to test that out
on. Oh, and Dell has some userspace tools that also use this interface
for adding new ids.
thanks,
greg k-h
On Tue, May 22, 2007 at 03:51:35PM -0400, Dave Jones wrote:
> On Tue, May 22, 2007 at 12:35:38PM -0700, Greg Kroah-Hartman wrote:
> > On Tue, May 22, 2007 at 03:04:08PM -0400, Jeff Garzik wrote:
> > > Greg KH wrote:
> > > > What's wrong with the current sysfs way of adding new device ids without
> > > > touching the kernel? Devices described above was the very reason we
> > > > added that functionality, so users would not have to constantly update
> > > > their kernel. The distros provide userspace tools that enable these ids
> > > > to be added and at boot time, everything "just works" properly.
> > >
> > > I haven't found a single distro that (a) makes it trivial to add PCI IDs at
> > > install time, and then (b) ensures those PCI IDs remain persistent for each
> > > boot. We are not at all to the "just works" stage yet.
> >
> > Well, SuSE handles this just fine, but I do notice that RHEL 5 disables
> > the new_id stuff entirely, so I can see why you might get this
> > impression :)
>
> That's news to me. I didn't even realise it was possible to disable this.
> Pointer?
Jon Masters told me this last week at FreedomHEC, so I don't have a
pointer to the patch that disables it, sorry.
> > I'm just trying to point out that the new_id sysfs stuff is there
> > explicitly for this very reason, as people were demanding that (Dell
> > being the major company behind it.)
>
> Theres more to this than just PCI IDs though.
> ac97 ID updates, usb id updates, etc, etc.
USB ids also can be added through sysfs :)
> We have many different forms of what are fundamentally, the same thing.
That's why we tried to have the same userspace interface in sysfs for
them all. We have PCI, USB, and USB-Serial already covered this way, if
people want more, we can add them too, it's not that hard.
thanks,
greg k-h
On Tue, May 22, 2007 at 03:00:44PM -0700, Chris Wright wrote:
> * Greg KH ([email protected]) wrote:
> > On Tue, May 22, 2007 at 03:04:08PM -0400, Jeff Garzik wrote:
> > > Really, it is just silly to think that one-line PCI IDs patches will cause
> > > any harm at all, and it should be self-evident that there is clear potential
> > > to HELP Linux users. That's why we're all here, right?
> >
> > So, if there is an overwhelming majority of people that strongly feel
> > that this is a good thing, fine, we can try it out.
>
> Yes, if it will serve -stable users better, we can give it a trial run
> to see how it goes.
Ok, let's try it. Send on the "only add a new device id" patches and
let's see how it works out.
But we still do reserve the right to stop doing this, if it turns out
that it causes more problems. Rembember, -stable should not be adding
new features, and I _really_ want to keep it that way, as it's the only
way that Chris and I can stay relativly sane...
thanks,
greg k-h
Chris Wright wrote:
> 2) In theory new hardware can seem to work with a simple PCI ID
> update, and later we find it needs extra quirk handling or specific
> driver support. This could mean adding buggy support for new hardware
> to -stable. In practice, hopefully this isn't a real issue.
No need to worry about theory. Since you are (or should be???) taking
stuff solely from upstream, you should already know what is needed, or not.
> 3) It hasn't been a pressing issue brought to our attention until this
> thread and its predecessor earlier in the month.
Search your email archives, it has been brought more than the two times
you cite.
> My own personal experience is each time I've needed a PCI ID update for
> new hardware it's also needed changes to the driver (read: e1000, every
> single time). So from my perspective neither sysfs nor relaxing -stable
> rules slightly would actually help provide support for new hardware,
> but that's clearly limited experience.
e1000 is not a representative sample at all...
Jeff
On Tue, May 22, 2007 at 03:17:18PM -0700, Greg Kroah-Hartman wrote:
> > > > I haven't found a single distro that (a) makes it trivial to add PCI IDs at
> > > > install time, and then (b) ensures those PCI IDs remain persistent for each
> > > > boot. We are not at all to the "just works" stage yet.
> > >
> > > Well, SuSE handles this just fine, but I do notice that RHEL 5 disables
> > > the new_id stuff entirely, so I can see why you might get this
> > > impression :)
> >
> > That's news to me. I didn't even realise it was possible to disable this.
> > Pointer?
>
> Jon Masters told me this last week at FreedomHEC, so I don't have a
> pointer to the patch that disables it, sorry.
Either there's some miscommunication, or bonghits.
(18:54:00:davej@gelk:kernel-2.6.18)$ kdiff vanilla/drivers/pci/pci-driver.c linux-2.6.18.noarch/drivers/pci/pci-driver.c
(18:54:10:davej@gelk:kernel-2.6.18)$
And as there's no CONFIG option other than CONFIG_HOTPLUG (which we obviously enable)
I don't see any reason why this wouldn't be enabled in RHEL5.
(And I think mdomsch would have probably had a fit if he found out we were
disabling it, but that's another story ;-)
> > Theres more to this than just PCI IDs though.
> > ac97 ID updates, usb id updates, etc, etc.
>
> USB ids also can be added through sysfs :)
oh cool, I had missed that.
Dave
--
http://www.codemonkey.org.uk
On Tue, May 22, 2007 at 06:56:40PM -0400, Dave Jones wrote:
> On Tue, May 22, 2007 at 03:17:18PM -0700, Greg Kroah-Hartman wrote:
>
> > > > > I haven't found a single distro that (a) makes it trivial to add PCI IDs at
> > > > > install time, and then (b) ensures those PCI IDs remain persistent for each
> > > > > boot. We are not at all to the "just works" stage yet.
> > > >
> > > > Well, SuSE handles this just fine, but I do notice that RHEL 5 disables
> > > > the new_id stuff entirely, so I can see why you might get this
> > > > impression :)
> > >
> > > That's news to me. I didn't even realise it was possible to disable this.
> > > Pointer?
> >
> > Jon Masters told me this last week at FreedomHEC, so I don't have a
> > pointer to the patch that disables it, sorry.
>
> Either there's some miscommunication, or bonghits.
>
> (18:54:00:davej@gelk:kernel-2.6.18)$ kdiff vanilla/drivers/pci/pci-driver.c linux-2.6.18.noarch/drivers/pci/pci-driver.c
> (18:54:10:davej@gelk:kernel-2.6.18)$
>
> And as there's no CONFIG option other than CONFIG_HOTPLUG (which we obviously enable)
> I don't see any reason why this wouldn't be enabled in RHEL5.
> (And I think mdomsch would have probably had a fit if he found out we were
> disabling it, but that's another story ;-)
I thought so too, which is why I was so surprised when Jon said it.
Jon, is this really true, or was it the symptom of the 3rd pot of coffee
you were on that day? :)
thanks,
greg k-h
* Jeff Garzik ([email protected]) wrote:
> Chris Wright wrote:
> >2) In theory new hardware can seem to work with a simple PCI ID
> >update, and later we find it needs extra quirk handling or specific
> >driver support. This could mean adding buggy support for new hardware
> >to -stable. In practice, hopefully this isn't a real issue.
>
> No need to worry about theory. Since you are (or should be???) taking
> stuff solely from upstream, you should already know what is needed, or not.
Yup, it's definitely handwavy. If it's a problem we can address it then.
thanks,
-chris
Hi!
> >So, because of that, I don't really see a need to be
> >adding new device
> >ids to the -stable tree.
>
> Maybe you are just not seeing all the developers that
> keep bringing this up??
>
> Really, it is just silly to think that one-line PCI IDs
> patches will cause any harm at all, and it should be
> self-evident that there is clear potential to HELP Linux
> users. That's why we're all here, right?
Well, in 2.6.73.1 we add 'trivial' one line to add new pci id, and in
2.6.73.2 we have data corruption, because that driver needed some
quirk we did not know about...?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek wrote:
> Well, in 2.6.73.1 we add 'trivial' one line to add new pci id, and in
> 2.6.73.2 we have data corruption, because that driver needed some
> quirk we did not know about...?
False argument. -stable should only be merging patches that are already
upstream, and known.
Jeff
On Tue, 2007-05-22 at 15:17 -0700, Greg KH wrote:
> >
> > Theres more to this than just PCI IDs though.
> > ac97 ID updates, usb id updates, etc, etc.
>
> USB ids also can be added through sysfs :)
>
FWIW,
With the asix.c driver, you can't just add the USB IDs and have it work.
Each ID also needs to be told which driver structure to use, since the
driver itself supports three similar, but distinct chips. Adding the
IDs to the driver itself is naturally trivial, but adding via sysfs or
the like doesn't work. I would imagine that there are other drivers
that operate quite similarly.
--
David Hollis <[email protected]>
David Hollis wrote:
> With the asix.c driver, you can't just add the USB IDs and have it work.
> Each ID also needs to be told which driver structure to use, since the
> driver itself supports three similar, but distinct chips. Adding the
> IDs to the driver itself is naturally trivial, but adding via sysfs or
> the like doesn't work. I would imagine that there are other drivers
> that operate quite similarly.
As is evident from the patches that do upstream (a requirement for
-stable), it depends on the driver. Some drivers work just fine with a
simple ID addition.
Review the thread, we are just talking about the patches where adding an
ID is the only work necessary.
Jeff
Hi!
> >Well, in 2.6.73.1 we add 'trivial' one line to add new
> >pci id, and in
> >2.6.73.2 we have data corruption, because that driver
> >needed some
> >quirk we did not know about...?
>
> False argument. -stable should only be merging patches
> that are already upstream, and known.
Well, then we should have some more requirements. 'Has been in
-rc2-git1 for 8 hours' is technically upstream, but it does not make
the patch 'known-enough' for stable. 'Have been in three release
candidates' seems like a rule we want here.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html