[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