These patches are just attempts to merge code from the ubuntu kernel tree.
This is most of the differences between our tree and stock code (not
necessarily all differences, since we do have a lot of external drivers
pulled in).
You can pull from:
master.kernel.org:/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git ubuntu-fixes
Or:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git ubuntu-fixes
diffstat:
arch/i386/kernel/acpi/boot.c | 10 ++
arch/i386/kernel/acpi/boot.c | 10 ++
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c | 10 ++
arch/i386/kernel/cpu/cpufreq/powernow-k7.c | 11 +-
arch/i386/kernel/reboot.c | 9 ++
arch/i386/pci/fixup.c | 8 +-
drivers/acpi/asus_acpi.c | 11 +-
drivers/acpi/processor_idle.c | 68 +++++++++++++----
drivers/char/sonypi.c | 46 +++++++++++-
drivers/input/misc/wistron_btns.c | 20 ++++-
drivers/input/serio/i8042-x86ia64io.h | 9 ++
drivers/macintosh/therm_adt746x.c | 40 ++++++----
drivers/macintosh/via-pmu.c | 5 +
drivers/net/irda/nsc-ircc.c | 103 +++++++++++++++++++++++++--
kernel/workqueue.c | 6 +
scripts/kconfig/conf.c | 19 ++++
16 files changed, 323 insertions(+), 62 deletions(-)
On Wed, 04 Jan 2006 16:59:02 -0500
Ben Collins <[email protected]> wrote:
> These patches are just attempts to merge code from the ubuntu kernel tree.
> This is most of the differences between our tree and stock code (not
> necessarily all differences, since we do have a lot of external drivers
> pulled in).
Why not submit them too?
--
Stephen Hemminger <[email protected]>
OSDL http://developer.osdl.org/~shemminger
On Wed, 2006-01-04 at 14:06 -0800, Stephen Hemminger wrote:
> On Wed, 04 Jan 2006 16:59:02 -0500
> Ben Collins <[email protected]> wrote:
>
> > These patches are just attempts to merge code from the ubuntu kernel tree.
> > This is most of the differences between our tree and stock code (not
> > necessarily all differences, since we do have a lot of external drivers
> > pulled in).
>
> Why not submit them too?
Because neither I nor Ubuntu maintains them as upstream. I would rather
leave it to the upstream authors of those drivers (e.g. rt2400, rt2500,
unionfs, etc.) to submit their own code to Linus.
--
Ben Collins <[email protected]>
Developer
Ubuntu Linux
On Wed, 04 Jan 2006 17:12:48 -0500
Ben Collins <[email protected]> wrote:
> On Wed, 2006-01-04 at 14:06 -0800, Stephen Hemminger wrote:
> > On Wed, 04 Jan 2006 16:59:02 -0500
> > Ben Collins <[email protected]> wrote:
> >
> > > These patches are just attempts to merge code from the ubuntu kernel tree.
> > > This is most of the differences between our tree and stock code (not
> > > necessarily all differences, since we do have a lot of external drivers
> > > pulled in).
> >
> > Why not submit them too?
>
> Because neither I nor Ubuntu maintains them as upstream. I would rather
> leave it to the upstream authors of those drivers (e.g. rt2400, rt2500,
> unionfs, etc.) to submit their own code to Linus.
>
Just want to needle the upstream drivers to submit and get reviewed.
--
Stephen Hemminger <[email protected]>
OSDL http://developer.osdl.org/~shemminger
On 1/4/06, Ben Collins <[email protected]> wrote:
> These patches are just attempts to merge code from the ubuntu kernel tree.
> This is most of the differences between our tree and stock code (not
> necessarily all differences, since we do have a lot of external drivers
> pulled in).
Hi Ben,
Just a note in case you don't receive feedbacks to all the patches,
it looks like you didn't CC the relevant maintainers.
Anyway, i really appreciate that you try to keep as in sync as
possible the Ubuntu kernel to the vanilla.
Ciao,
--
Paolo
On Wed, 2006-01-04 at 14:30 -0800, Stephen Hemminger wrote:
> On Wed, 04 Jan 2006 17:12:48 -0500
> Ben Collins <[email protected]> wrote:
>
> > On Wed, 2006-01-04 at 14:06 -0800, Stephen Hemminger wrote:
> > > On Wed, 04 Jan 2006 16:59:02 -0500
> > > Ben Collins <[email protected]> wrote:
> > >
> > > > These patches are just attempts to merge code from the ubuntu kernel tree.
> > > > This is most of the differences between our tree and stock code (not
> > > > necessarily all differences, since we do have a lot of external drivers
> > > > pulled in).
> > >
> > > Why not submit them too?
> >
> > Because neither I nor Ubuntu maintains them as upstream. I would rather
> > leave it to the upstream authors of those drivers (e.g. rt2400, rt2500,
> > unionfs, etc.) to submit their own code to Linus.
> >
>
> Just want to needle the upstream drivers to submit and get reviewed.
After dealing with literally dozens of upstream drivers, I think the
reasons boil down to a few categories:
1 - They know their code is crappy and they don't want to deal with code
review.
2 - They want to retain total control of their code. Having it in the
kernel tree means that the driver can be modified by others (in usually
correct ways) without their consent. They don't want to have to track
these changes and accommodate them. Also, external drivers tend to
retain a lot of backward compatibility for older kernel versions, that
would surely be dropped if it was placed in the kernel proper.
3 - They don't think their driver is important enough. They have a small
user base, and deal directly with those users.
4 - They just don't know how.
Not defending any of these reasons. I'd love to not have all this work
of pulling in and tracking the drivers that our users need/want, but
it's going to be a lot of work. Maybe I'll start emailing them about
getting their code in the kernel tree.
--
Ben Collins <[email protected]>
Developer
Ubuntu Linux
On Wed, 04 Jan 2006 17:45:39 -0500
Ben Collins <[email protected]> wrote:
> On Wed, 2006-01-04 at 14:30 -0800, Stephen Hemminger wrote:
> > On Wed, 04 Jan 2006 17:12:48 -0500
> > Ben Collins <[email protected]> wrote:
> >
> > > On Wed, 2006-01-04 at 14:06 -0800, Stephen Hemminger wrote:
> > > > On Wed, 04 Jan 2006 16:59:02 -0500
> > > > Ben Collins <[email protected]> wrote:
> > > >
> > > > > These patches are just attempts to merge code from the ubuntu kernel tree.
> > > > > This is most of the differences between our tree and stock code (not
> > > > > necessarily all differences, since we do have a lot of external drivers
> > > > > pulled in).
> > > >
> > > > Why not submit them too?
> > >
> > > Because neither I nor Ubuntu maintains them as upstream. I would rather
> > > leave it to the upstream authors of those drivers (e.g. rt2400, rt2500,
> > > unionfs, etc.) to submit their own code to Linus.
> > >
> >
> > Just want to needle the upstream drivers to submit and get reviewed.
>
> After dealing with literally dozens of upstream drivers, I think the
> reasons boil down to a few categories:
>
> 1 - They know their code is crappy and they don't want to deal with code
> review.
Then find some friendly reviewers. It doesn't have to be a "throw crap
over the wall and see what flys back review". If it has dicey locking
and race issues, then the security and reliability of the whole system
is effected.
> 2 - They want to retain total control of their code. Having it in the
> kernel tree means that the driver can be modified by others (in usually
> correct ways) without their consent. They don't want to have to track
> these changes and accommodate them. Also, external drivers tend to
> retain a lot of backward compatibility for older kernel versions, that
> would surely be dropped if it was placed in the kernel proper.
And therefore their driver gets broken regularly. The modified by others
is almost always for small compatibility stuff.
> 3 - They don't think their driver is important enough. They have a small
> user base, and deal directly with those users.
If it is important enough for Ubuntu to ship, then it probably is important
enough to get out of the closet.
> 4 - They just don't know how.
Which is true, unfortunately, unless they read about it on a regular basis,
most people will plead ignorance.
> Not defending any of these reasons. I'd love to not have all this work
> of pulling in and tracking the drivers that our users need/want, but
> it's going to be a lot of work. Maybe I'll start emailing them about
> getting their code in the kernel tree.
I don't mean to play shoot the messenger, you are helping a lot by doing this
I wish every distro did.
--
Stephen Hemminger <[email protected]>
OSDL http://developer.osdl.org/~shemminger
On Wed, Jan 04, 2006 at 03:06:58PM -0800, Stephen Hemminger wrote:
> > Not defending any of these reasons. I'd love to not have all this work
> > of pulling in and tracking the drivers that our users need/want, but
> > it's going to be a lot of work. Maybe I'll start emailing them about
> > getting their code in the kernel tree.
>
> I don't mean to play shoot the messenger, you are helping a lot by doing this
> I wish every distro did.
FWIW, Red Hat has been under constant pressure from users asking us
to merge driver x 'because $otherdistro has it' for a long time.
The first reason we say no 99.9% of the time is because to stay in
a position where we can quickly rebase to a new upstream release, you
have to be light enough to not have to spend a day rediffing/fixing
add-on patches.
The second reason (and this is actually more important than the first,
but as I'm a selfish sod, I thought of my own wellbeing first), is that
historically there have been some vendors who have taken the position
"Our driver is in Red Hat's distro, we don't care about anyone else".
For obvious reasons, this isn't a good thing, and something we now
go out of our way to discourage.
>From time to time, we do carry drivers that aren't upstream yet.
ipw2x00 got a good beating in RHEL4 & FC3 before it made it into Linus' tree.
A lot of issues were found in that driver early on by rhel beta-testers,
which Intel went and fixed, long before it was proposed for upstream inclusion.
Whilst some of those issues would probably have been found by -mm exposure
eventually, living in a distro tree gets it a lot more exposure.
Getting 'previews' of drivers into the grubby hands of end-users
who are prepared for a bumpy ride, and are prepared to give feedback
to improve things is invaluable.
For Fedora at least, I don't object to the notion of carrying a handful
of continually improving drivers which are making progress at upstream
inclusion. What I don't want to entertain is the idea of grabbing
random drivers and dumping them in the distro tree just because their
upstream has no motivation at getting them merged in Linus' tree.
(Which is sadly a category quite a few of the requests that we get
fall into)
Dave
>> > These patches are just attempts to merge code from the ubuntu kernel tree.
>> > This is most of the differences between our tree and stock code (not
>> > necessarily all differences, since we do have a lot of external drivers
>> > pulled in).
>>
>> Why not submit them too?
>
>Because neither I nor Ubuntu maintains them as upstream. I would rather
>leave it to the upstream authors of those drivers (e.g. rt2400, rt2500,
>unionfs, etc.) to submit their own code to Linus.
The maximum where unionfs should IMO go ATM is -mm, because it still has
refcount issues and occassional crashes.
rt2400/etc is a bit more tricky. There exist several versions and they
all have different levels of evolution :-/
Group 1:
- rt* from ralink.com.tw
Group 2:
- rt2400,rt2500,rt2570 "1.1.0" from sf.net/projects/rt2400
- rt2x00 "2.0", also sf.net/projects/rt2400
Nevertheless, I do have rt* 1.1 and 2.0, and unionfs in my patchset...
Jan Engelhardt
--
On Wed, 2006-01-04 at 17:45 -0500, Ben Collins wrote:
> After dealing with literally dozens of upstream drivers, I think the
> reasons boil down to a few categories:
> <...>
You missed one:
5 - They've implemented Yet Another IEEE802.11 stack instead of
embracing and extending the Intel one we already have, and are hence
urinating into the atmospheric disturbance.
That's one of the reasons why I merged bcm43xx and softmac into the
Fedora kernel and none of the others, FWIW -- Johannes is actually
working on improving what we have in the kernel, rather than just saying
"You have to throw it all away because $MYSTACK is better". So I figure
softmac has a _much_ better chance of going upstream, even if its
feature list isn't quite as comprehensive yet.
http://softmac.sipsolutions.net/softmac-2.6.git
--
dwmw2
On Thu, 2006-01-05 at 15:46 +0000, David Woodhouse wrote:
> On Wed, 2006-01-04 at 17:45 -0500, Ben Collins wrote:
> > After dealing with literally dozens of upstream drivers, I think the
> > reasons boil down to a few categories:
>
> > <...>
>
> You missed one:
>
> 5 - They've implemented Yet Another IEEE802.11 stack instead of
> embracing and extending the Intel one we already have, and are hence
> urinating into the atmospheric disturbance.
>
> That's one of the reasons why I merged bcm43xx and softmac into the
> Fedora kernel and none of the others, FWIW -- Johannes is actually
> working on improving what we have in the kernel, rather than just saying
> "You have to throw it all away because $MYSTACK is better". So I figure
> softmac has a _much_ better chance of going upstream, even if its
> feature list isn't quite as comprehensive yet.
Yeah, I did the same for bcm43xx (it's in the ubuntu tree, and working
on my powerbook right now with wep :)
Didn't notice softmac had a git tree now. And here I am pulling from
mercurial and hand merging :/
> http://softmac.sipsolutions.net/softmac-2.6.git
--
Ben Collins <[email protected]>
Developer
Ubuntu Linux
Jan Engelhardt <[email protected]> :
[...]
> rt2400/etc is a bit more tricky. There exist several versions and they
> all have different levels of evolution :-/
> Group 1:
> - rt* from ralink.com.tw
Too much work to merge imho.
> Group 2:
> - rt2400,rt2500,rt2570 "1.1.0" from sf.net/projects/rt2400
> - rt2x00 "2.0", also sf.net/projects/rt2400
Afaiks it does not apply to the rt2x00 drivers. However these are still
strongly different from the ideal in-kernel driver. CodingStyle (arguable)
and locking - broken - would need more work. This is not yet another
80211 subsystem but it is not clear if the authors/maintainers plan to
merge their stuff in a near future.
--
Ueimor
On Thu, Jan 05, 2006 at 07:52:06PM +0100, Francois Romieu wrote:
> > Group 2:
> > - rt2400,rt2500,rt2570 "1.1.0" from sf.net/projects/rt2400
> > - rt2x00 "2.0", also sf.net/projects/rt2400
>
>
> Afaiks it does not apply to the rt2x00 drivers. However these are still
> strongly different from the ideal in-kernel driver. CodingStyle (arguable)
> and locking - broken - would need more work. This is not yet another
> 80211 subsystem
Currently this is true, but AFAIK they intend to switch to the DeviceScape
stack right now (between rt2x00 2.0b3 and 2.0b4).
Dominik
>These patches are just attempts to merge code from the ubuntu
>kernel tree.
Please send patches that touch acpi files to me, cc: [email protected]
thanks,
-Len