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,
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
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
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
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.
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,
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
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.
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
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
* 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
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
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
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
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
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
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
>
* 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.
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.
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
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
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
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
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
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
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)
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)
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
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
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
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
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
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
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.
* 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
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.
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
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
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
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
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
* 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,
42 matches
Mail list logo
