[Desktop_architects] raw notes from kernel discussion 12/02/2005

Christopher Blizzard blizzard at redhat.com
Fri Dec 2 14:59:45 PST 2005


Kernel Meeting 12/02/2005

[ these names aren't even close to being spelled right ]

Chris Wright - kernel hacker / xen hacker

Gerrit H - IBM LTC

pat mochelle 

why don't kernel developers care about the desktop?
they do

lots of talk about drivers, lots of talk about binary drivers, lots 

rule: "NO STABLE INTERNAL API/ABI"

misinterpreted - external abi is stable, internal is not

rule: "MERGE DRIVERS UPSTREAM"

we need help as an industry: a lack of documentation for all the major
peripherals

OSDL pilot program to get specs only available under an NDA for
developers who can't provide them

can we do a clean room code from windows source code? not considered yet
- legal nightmare

sometimes they will give us the source and will make it available - have
to avoid cross-pollution of code

did they include any MS code?

kernel will only take GPL code

action: to examine this question and how to solve it
problem: need to have cross-driver model skills

rule: PROBLEMS NOT SOLUTIONS

understanding the problem and the use cases is important

multiple camps inside the kernel cause confusion and wasting investment

understanding both sides of the problem is important

inotify breaks down in the corner cases?  kernel deadlocks?  al viro
saying "what problem are you trying to solve?"

disconnect in the communication - have to be able to make tradeoffs

increasing number of contributions

inotify came from someone who knows both the desktop and the kernel

alan cox is another example

conflicting visions of how the kernel should work 

some people saying "that's dumb, you shouldn't do that"

need more people to cross boundaries and build relationships

kernel can put forth its own experts

WIFI desktop manfacturers API from OSDL?  the current maintainer doesn't
really care - no leadership here

readahead sounds like a hack for boot time
readahead speeds up diff for linus!

probably some room for improvement
who needs to be involved to solve the larger problem?

has to be solved - problem is the problem statements

power management from pat - he's a good contact

from intel

driver model in 2.6 power management
in linux it sucks
powerbook raises the bar
makes the batter last for hours - ours last half as much time
in the next year we'll see a lot of changes
least year before OLS - power management summit
spent a day talking about suspend/resume
another day talking about those
another summit in april
want to include desktop people and distro folks
maybe 15 people
sponsors and who to send
key issue is that the kernel folks don't include the desktop in their
thinking
need the interactions with the desktop folks

most of it is an infrastructure problem
goals: increase battery life and power consumption

optimizing the system - CPU power management
performance states for devices
video: accel device is shut down when it's not being used
shutting off devices when you're not using them
kernel folks know what it's going to take to make it happen but need to
do the work and it happens smoothly and controlled from the desktop
policy manager for communication?
laptop has two basic modes: want to communicate easily
desktop needs to drive the base usage
historical ACPI problems?  most have been worked out
ACPI team has been very good
vendors are actually pretty good because of the huge ACPI test suite
good incentive would be "make it better/faster/etc"

new problem over the next 12 months: an SMP desktop?  how do you
optimize the desktop?  the apps?  when do you shut off one of those
CPUs?

policy vs. mechansim again
no runtime power management infrastrcuture: drivers don't have a way to
say they _can_ save power.  no mechanisms for doing that.
how do the windows and the mac do this?
OSX has a great situation because they only have to support one set of
devices
linux has a centralized driver model
laptops often ship with a slightly different OSs
hardware and component vendors have really stringent model and branding
model to make it work with windows so power management does work
windows is getting better over time - we're in a bit of a race

real time in the kernel today is pretty good, but not as good as the RT
patches?
distros don't set up the policy properly
audio development people do a lot of testing with RT patches
2.6.14 is going to work for almost all consumers

training for vendors? steep learning curve
OS drivers on OSDL
geography is important here - US + india + taiwan
takeaway: training and documentation are works in progress

plug and play
hot plug ide for some stuff sata, scsi
devices and hotplug - sometimes the kernel needs to be fixed
file bug reports!
udev - depends on who you ask

feature and distro lag - bootup time used to be painful from udev

usefulness in: organize small events for getting people into the same
room are really successful
hotplug! wireless! get them together with the people who have to depend
on them





More information about the Desktop_architects mailing list