[Ksummit-2008-discuss] proposal for discussion..

[Marcel Holtmann]

Hi Dave,

>>> Sounds like there's enough contention around this subject for it  
>>> to be
>>> a worthwhile slot. (And also, it's possibly one of the most  
>>> controversial
>>> ones so far, and we need some of that to keep us awake for the two  
>>> days :)
>>>
>>> The thing that I'm not getting from the proposal though is
>>> "and here's what we'd like to do about it"
>>
>>
>> Indeed; this worries me as well.  The other question I have is if we
>> have the right people on both sides of the kernel/userspace divide to
>> handle these topics, or whether some or all of them are more properly
>> Plumber's topics.
>>
>> We can try to articulate some general principles, but I'm not sure
>> there's a whole lot to say here.  And if we're going to do specific
>> topics, such as graphics and wireless (which could be their own
>> specific slots), I think we need something a bit more concrete than
>> "we've had problems here", and then make sure we have the right folks
>> attending the conference.
>
> Well I was more thinking about places where the same group dealt with
> both kernel and userspace sides,
> so I'm not really thinking about stuff where HAL just sits on top and
> helps to abstract stuff or even glibc type things. I'm
> thinking about subsystems which exist and have rats nest of user
> interfaces using ioctls or netlink or sysfs.
>
> A lot of the kernel subsystems exist as part of a much larger Linux
> subsystem, and developing solutions for
> these areas is quite different than say writing a block device driver
> or filesystem. I sometimes feel that many maintainers
> don't realise that a difference exists at all, and would like to get
> some feedback from other kernel maintainers about how
> we can deal with these systems in a consistent manner, instead of each
> maintainers reinventing the wheel everytime.
>
> So I don't think plumbers is the place for this, and if I knew what to
> do about it, I would be doing it instead of
> suggesting it as a topic for the kernel summit. I have some ideas on
> how to deal with it, but they aren't really concrete.
>
> The main problems people developing these subsystems face are:

the real problem here is that getting a new API into the kernel is  
pretty simple. Then when you and others start using it, you realize  
that it is actually broken and wrong for whatever matter, then what to  
do? Getting the API back out of the kernel is the hard part.

Most times we make sure that the userspace part can deal with an old  
or new API in whatever fashion. Just by disabling the feature or  
performance decrease or something alike. Then we keep pushing a  
userspace with this bloat for two years or longer and then remove the  
old API from the kernel and the userspace. And people are still  
complaining.

Getting users quickly a recent userspace and newer kernel versions is  
the key feature here. This can take 6 month or if we talk Enterprise  
distros almost a decade :)

Regards

Marcel