[Ksummit-discuss] Late KS topics

[Hannes Reinecke <hare@suse.com>]

(I just realized that I should've sent it to ksummit-discuss, too.
 So here it is.)

Hi Ted,

here are the two things I'd like to bring up:

- Asynchronous probing
  Currently, the driver model has the simple match/probe mechanism by
which individual drivers can attach to device. As per design, these
device are enumerated by the 'bus', and the match/probe pair is
executed for each device. As this is a simple loop, each match/probe
pair is executed sequentially.
This creates quite a significant slowdown on large installations, where
eg. the PCI bus is scanned sequentially, and probe() is called for every
device, although in fact each device is totally independent,
so there isn't really a need for the probe function to be serialized.
I would like to discuss the implications of moving to asynchronous
probing in general, either per bus in with the driver core in general.

The topic will be presented by me an Luis Rodriguez; possible slot would
be 11 or 14.


The other topic is a rather short one, which possibly could be move to
a lightning talk:
- printk usecases
  Currently, printk is used for two largely different usecases:
  1) Really urgent, 'ship me out at any cost now' messages
  and
  2) Rather longish, 'and incidentally I always wanted to tell
  you what I did on my recent holidays' type of logging entries.
  As it so happens, this really makes it hard to do any improvements
  for printk as it inevitably messes up one or the other side.
  (This whole idea came up as we've had some instances which simply
   could not boot as the serial console took too long to print out
   all the stuff, so systemd timeout kicked in and killed the udev
   process which should have handled the boot device.)
  The talk/proposal should be used to come to a consensus about
  restricting printk() to high-priority, small volume messages,
  and implement a different call (like log_printk()) for the
  low-priority, high-volume traffic.

Cheers,

Hannes