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.
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?
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
procfs for processes and devfs for devices (?), so before I start with
my infofs what are people expect me doing?
> > 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? (:
Ciao,
Robert (-:
> > 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?
|