Robert Siemer writes:
> From: Richard Gooch <rgooch@xxxxxxxxxxxxxxx>
> > Robert Siemer writes:
>
> > > I'm writing a device driver for my RDS radio tuner. I need to create
> > > some files in /proc/rds/radio0/. To get the correct name of my radio
> > > (radio0 in this example) I want to fetch it from the
> > > video_device.devfs_handle->name pointer.
> >
> > Hm. Might it perhaps be cleaner to create your extra files in devfs
> > instead? procfs has been overloaded from it's original purpose, but
> > now that we have devfs, we don't have to continue with the same
> > brokenness.
>
> sndstat went from /dev/ to /proc/. Now I would expect human readable
> information in /proc, not in /dev. Maybe others, too. This wasn't my
> idea.
I think sndstat went into procfs because someone wanted a dynamic
entry and wanted a pretend regular file. And since devfs took such a
long time getting into the kernel...
> Generally: why don't we have /dev in /proc or /proc in /dev??
> What is devfs/procfs capable of, that is not possible in procfs/devfs?
These days the differences aren't as great as they used to be, but
still, devfs is designed for device management (i.e. has a simple API
and has a protocol for passing events to a daemon) whereas procfs is
designed for process management which has had some device support
kludged in.
There is an argument for splitting procfs into a real-procfs and a
kernfs. The latter being for getting and setting kernel parameters.
This would clean up procfs.
In the long term, if the VFS continues to mature, it may be possible
to vastly reduce the code and data for procfs and devfs (effectively
sharing code and data structures).
But put simply, the distinction is this: procfs is for processes and
devfs is for devices/drivers.
> But currently I'm working on another part of the kernel, namely my rds
> radio tuner and I want to have somthing like this:
> rds/radioX/rt (RadioText)
> rds/radioX/ct (Clock and Time)
> rds/radioX/ms (Music/Speech)
> rds/radioX/ps (station name)
> rds/radioX/pty (Programme Type)
> ...
>
> $ cat rds/radioX/ps
> SWR3
> $ cat rds/radioX/rt
> Michael Jackson ** Up and Down
Sure. You can do this quite easily with devfs. Also, devfs makes
management of a directory tree easy. Just unregister the directory and
all the stuff underneath is automatically unregistered.
> > > devfs_get_name() is not exported, so I cant use it with my
> > > device.devfs_handle.
> > >
> > > Is there any reason to not export it?
>
> > No. I just forgot to export it.
>
> Will you include it for me? (:
Erm, OK. Just remind me every week until I do it. I've recently gotten
back from a long trip and my life is a disaster right now :-(
> > > PS: Can I do something against modprobe race conditions with devfsd?
> >
> > Which race conditions are you talking about?
>
> When I started to use devfs(d) a 'LOOKUP .* MODLOAD' in
> /etc/devfsd.conf could look up my system with modprobe eating CPU and
> I was unable to login or start kill... - I try to avoid this; maybe
> it was a modprobe problem or a module which didn't finished its
> init(), I don't know...
> Nobody else had this probleme here? Is this completly unknown?
I vaguely recall something like this. It was a modutils bug.
Always make sure you have the latest modutils before filing a bug
report :-)
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|