Robert Siemer writes:
> devfs consists of two different kinds of entries. "Real" and
> "artificial" (e.g. symlinks, devices via mknod) ones.
>
> Here a table which events devfsd gets:
>
> real artificial
> arise REGISTER CREATE
> change CHANGE CHANGE
> vanish UNREGISTER DELETE
>
> If there is still nothing: LOOKUP
>
> With this knowledge it was easier for me to reunite the two approaches
> for permisson-persistens (copy in /dev-state/) and artificial entries
> (special configuration in /etc/devfsd.conf).
>
> So my devfsd.conf is looking like this (remove comments):
>
> REGISTER .* COPY /dev-state/$devname $devpath # arise real
> CREATE .* COPY $devpath /dev-state/$devname # arise artificial
> CHANGE .* COPY $devpath /dev-state/$devname # change (both)
> DELETE .* CFUNCTION GLOBAL unlink /dev-state/$devname
> # vanish artificial
> # (vanish real is uninteresting)
> LOOKUP .* MODLOAD # could be "real"
> LOOKUP .* COPY /dev-state/$devname $devpath # maybe artificial
>
> "New" (and not recommended in standard devfsd.conf) is just the
> handling of the events DELETE and LOOKUP.
This is a reasonable approach. I implemented the DELETE event
specifically for better persistence management. However, your approach
requires a hook into the LOOKUP event. This means the kernel has to do
an upcall to devfsd. If you're doing module autoloading anyway, this
is not an issue. However, if you're like me, and don't do module
autoloading, and don't want to have the LOOKUP upcall overhead, a
different approach is required.
I'll be adding code to devfsd to support grabbing inodes/permissions
at startup from a directory tree, and populating devfs with this. This
will not require a LOOKUP event hook.
> While DELETE is not working for me (but I don't want to call it a bug
> before I try the latest devfs) LOOKUP is performing good. It let's me
> going without special entries in /etc/devfsd.conf.
You need to grab devfs-patch-v184 or later and apply.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|