required/suggested devfs userland tool functionality
Alex
ahornung at gmail.com
Mon Jul 6 09:55:37 PDT 2009
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 at 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 / \
>
More information about the Users
mailing list