[opensolaris-summit] OS Summit topic proposal

[Garrett D'Amore]

Alan DuBoff wrote:
> On Fri, 21 Sep 2007, Garrett D'Amore wrote:
>
>> Seth didn't cover GLD (neither v2 nor v3) nor STREAMs drivers at all 
>> (all NIC drivers are STREAMs drivers).
>
> Well, sure his presentation was not intended to do that, he had to 
> dumb it down as it was and was constrained to about 45 minutes. A big 
> round of applause for Seth in being able to work around those 
> contraints and requests from Intel to dumb it down.

This wasn't a complaint.  Just a statement... STREAMs programming is 
very different from most other kinds of programming, and requires a 
unique mindset.  As it was, I think Seth probably tried to cover too 
much too quickly.

I *know* the material he covered cold, and quite frankly, my eyes were 
starting to glaze over during the session.  Again, this is no fault of 
Seth's.... its just not practical to cover kernel programming in an hour.

I believe a series of lectures, perhaps posted on-line, would be 
better.  If I were designing a kernel class today, I'd break it up into 
a series of lectures like this:

*) Simple kernel mode programming/fundamentals.
    - compiling a kernel module
    - memory allocation considerations
    - simple debug strategies
    - DDI/DDK
    - sources of other info
    - this might include a simple bug fix to an existing module
    - link flags... kernel linker dependencies (e.g. using -N xxx/xxx)

*) Autoconfiguration.
    - minor numbers, major numbers
    - the device tree
    - kinds of kernel modules
    - clone drivers
    - pseudo-drivers
    - device binding
    - libdevinfo (userland)
    - detach, attach, getinfo, probe
    - module _ini, _fini, _info entry points
    - dynamic reconfiguration

*) Character and Block Drivers
    - entry points to implement
    - strategy(9e)
    - memory mapping (mmap, etc.)
    - copyin, copyout
    - mapping device registers
    - interrupt framework
    - DDI access functions (ddi_get32, etc.)

*) Kernel synchronization and threadng
    - mutexes, condition variables
    - taskqs
    - timeout
    - (maybe?) cyclics
    - other clock/timing issue (lbolt, etc.)
    - "contexts" (interrupt, kernel, user)

*) 32- versus 64-bit programming
    - ioctl and pointer passing... type conversion macros
    - dangers... pointer/integer conversions, etc.
    - kernel memory maps

*) Kernel statistics facility
    - how kstat works, sample code, etc.

*) STREAMs drivers
    - messages, put, putnext, all the other good stuff.
    - you cannot be a STREAMs driver and a character/block driver
    - STREAMs perimeters
    - other synchronization issues (thou shalt not sleep!)
    - message types (M_DATA, M_IOCTL, etc.)
    - copyin/copyout techniques for streams (M_COPYIN, etc.)

5) Network drivers
    - description of DLPI
    - GLDv2
    - GLDv3

*) SCSI HBA drivers (SCSA)

*) USB drivers
    - kernel apis
    - libusb
    - special binding issues.

*) Dynamic Reconfiguration
    - detach, attach issues
    - rcm
    - dacf (?)

*) Power management
    - suspend/resume
    - device power management topics

*) Testing and debugging
    - test tips
    - kmdb/mdb
    - DTrace intro

Its possible that the break up is not ideal, but this is just a rough 
draft of what I'm thinking about.  I've no idea how such a series of 
lectures could be developed, however.

>
>> What I saw convinced me of the utter foolishness of trying to cram a 
>> week's worth of teaching material into one hour.
>
> Absolutely agreed.
>
>> However, I could probably present a simple GLDv2->v3 presentation 
>> class. That can be done in an hour if the attendees have at least a 
>> tiny inkling of kernel programming.
>
> That would be excellent, where would you do that? Not for the summit, 
> is it? I mean, that really doesn't fit in with the topics at the 
> summit, the summit will most likely be discussing how we could 
> incorporate drivers that are not in OpenSolaris today, not write new 
> ones, but maybe I'm mistaken.

I dunno.  I was just offering.  Its looking like the Summit is going to 
be about governance and community topics, and have little to do with 
code... to the point that I'm not sure if any actual developers are 
going other than myself. 

That bothers me somewhat.  If there is a big disconnect between the 
engineers doing the work, and the folks who are going to be making 
policy, we're setting ourselves up for heartache later.  It somehow 
doesn't feel right that a bunch of folks who aren't actually involved 
intimately with the practice of engineering should be determining 
exclusively the processes which engineers must follow.

Of course, if this is just a pow-wow of marketing type folks who are 
mostly interested in figuring how to *market* OpenSolaris to the rest of 
the world, then maybe there's not much point in folks who are mostly 
interested in development from attending.  (And that would, for the most 
part, include me.   Don't get me wrong, I'm as keen as the next person 
to improve OpenSolaris adoption, but talking about web pages and 
marketing priorities just doesn't really turn me on.)

>
>> I don't mind covering other topics, and one could probably do a 
>> whirlwind tour of kernel/driver APIs in a day, if one had the entire 
>> day to do it.
>
> I think preparing a session on that would be good to have for the 
> appropriate venue, certainly.

See above.  Probably there are a lot of sessions.  I don't think we have 
any other venue atm, but maybe I'm mistaken?

    -- Garrett