On Fri, 2004-09-24 at 10:14, Evgeniy Polyakov wrote:
> On Fri, 2004-09-24 at 09:48, Luis R. Rodriguez wrote:
> > On Fri, Sep 24, 2004 at 07:40:32AM +0400, Evgeniy Polyakov wrote:
> > > On Fri, 2004-09-24 at 01:54, Luis R. Rodriguez wrote:
> > > > RFC: 
> > > > 
> > > > Can and should we work towards using this as interface for drivers that
> > > > need callbacks from an external (closed source) library/HAL?
> > > 
> > > As I mentioned to Richard Jonson, it can be considered as
> > > ioctl. ioctl-ng!
> > > Unified interface (as ioctl) can be used for any type of modules.
> > > It is just a bit extended ioctl :)
> > > 
> > > And _yes_, it can be used to turn on/off binary-only callbacks.
> > > Remember pwc - closed part can register callback and open part can
> > > send message, or even closed part can register notification when
> > > open part registers itself and begin to "trash the kernel".
> > > 
> > > I understand that it is not right way to include it is into the kernel,
> > > but I personally do not understand how it is different 
> > > from just extended ioctl. It was designed to be usefull and convenient,
> > > and it is.
> > > 
> > > BTW, any binary-only module can _itself_ create netlink socket
> > > with input callback. And that is all - it will be absolutely
> > > the same as above.
> > > 
> > > One may consider connector as yet-another-netlink-helper.
> > > 
> > 
> > Eh. I'm just wondering if there's any *right* way of using binary
> > callbacks on a linux driver so that it doesn't *taint* and possibly
> > *trash it*, as you said. I was wondering if perhaps through the
> > connector we could somehow protect the kernel of possibly ill-behaved callbacks.
> > 
> > Comments?
> 
> Yes, we can.
> Connector itself has quite enough information about it's registrants.
> 
> For example if it is somehow not good module( for example without GPL in
> it's license string) then connector can be extended to call it's
> callback from thread or in jail. If it is of interest I will think of
> some plugable mechanism for callback environment( probably provide
> ->before_callback() and ->after_callback() methods from external policy
> provider which may check callback data and/or confine callback execution
> ? ).
> 
> We also may confine closed modules from being able to use event
> notification. In this scenario with worned out pwc-closed/open,
> situation will not differ from what we have now.

BTW, it can also restrict userspace event notification in following way:
when someone sends a message to notify group A of
registering/unregistering of device with id {x,y} then connector can
check if this group A is registered through callback_register_gpl(it is
not exist for now, but can be created as a copy of callback_register() )
or not. If it is GPL - send notify, else - execute 
"mail -s "shit happens" linux-kernel@vger.kernel.org" 
in the way /sbin/hotplug is called.
BTW, this decision also can be obtained from external policy module.

As you may think connector in current implementation is quite powerful
interface( if I will not praise it, who will? :) ), and somebody can
make bad things a bit easier with it, but it is also very flexible and
can be tuned to suit your needs.

I'm open for discussion :)

> > 	Luis
-- 
	Evgeniy Polyakov

Crash is better than data corruption. -- Art Grabowski