Re: required/suggested devfs userland tool functionality

[Alex <ahornung@xxxxxxxxx>]

As a matter of fact I only intended to do partial string matching, at
best a few special formatters or so to specify a beginning or end of a
string.

Do we need anything besides that? In my opinion you normally would
want to match them by prefix or device group (ad*, da*, ...) or so, no
need for fancy regexps... And also I'd prefer not having to rely on a
daemon to do all the ruling, it's probably safer and easier to just
load rules.

As for chmod/chown, you can already use that; that hasn't much to do
with the userland tool.


Cheers,

Alex

2009/7/6 Simon 'corecode' Schubert <corecode@fs.ei.tum.de>:
> Matthew Dillon wrote:
>>
>> :2) let the userland tool load a whole set of rules (for each devfs
>> :mount point) into the kernel. In turn the kernel applies the set of
>> :rules every time a device is attached. This has several advantages:
>> :- userland wouldn't have to be asked for every device attach
>> :- rules would continue to be applied even if the userland tool isn't
>> running
>> :- for that same reason, userland tool wouldn't have to be a daemon.
>> :
>> :While I prefer the second approach, I would like to hear your thoughts
>> :about this before making a final decision on which one to use. I'd
>> :also welcome suggestions of other things you think the userland devfs
>> :tool should be able to do.
>> :
>> :Cheers,
>> :Alex Hornung
>>
>>    I like the second approach.   Particularly since you already have a
>>    a VOP interface so loading the rules into devd could be as simple as
>>    doing a write() to a special node in devd.
>
> But do you really want to perform regexp/glob matching in the kernel?  Or do
> you want to restrict the users to prefix matching?
>
> I think we basically need to deal with multiple things here:
>
> 1. no race conditions when creating device nodes
> 2. give the user enough flexibility
> 3. allow the user to use chmod/chown?
>
> I don't have an opinion yet what is better, but maybe we should assess which
> kind of rules a user is expected to write (which rules do we want to ship
> per default?), and then we can decide whether it is worthwhile to put the
> rules management in the kernel, or whether it better goes into userland.
>
> cheers
>  simon
>
> --
>  <3 the future  +++  RENT this banner advert  +++   ASCII Ribbon   /"\
>  rock the past  +++  space for low CHF NOW!1  +++     Campaign     \ /
> Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
> Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \
>