Hi again!
I rewrote the underlying two drivers (aci.c and radio-miropcm20.c), so
it took a while...
Now, for my rds-miropcm20.c I wanted to export the name of the
v4l radio device (radio0 or radio1 or ...) to be able to mkdir
/proc/rds/radioX/.
This lead to a discussion on the devfs-ml - I've attached the last
mail from Richard Gooch.
My question is now: do we go with Richards suggestion and use devfs
instead of procfs, Russell?
From: Russell Kroll <rkroll@xxxxxxxxxxxx>
> > Okay. How the raw data socket looks like is currently your choice. (:
>
> Maybe not quite that complicated, though:
>
> $ cat /proc/rds/radio0/raw/3a
> < last 3A block returned here >
>
> I figure it will let the kernel space stuff parse it into something that's
> logically organized, then let userspace actually figure out what it means.
I found something about 'raw RDS' in
linux/Documentation/video4linux/API.html at the bottom.
> > $ cat /proc/rds/radio0/type
> > 08 Science
>
> This should just be 08, which handles your next issue nicely...
>
> > And how to switch form RDS to RBDS (08 Soft Rock :)?
>
> ... namely, to let the locale stuff handle which table to use. (...)
Is this case I would prefer just '8' without leading zeros, okay?
> I'll try to figure out some foundation work for this over the weekend so
> we can play with the code and work out the arrangement of the data.
I've already integrated two rds-dependant things via the v4l api:
When RDS is availabe I show this with VIDEO_TUNER_RDS_ON on
VIDIOCGTUNER-ioctl().
Further I refine video_tuner.signal with the RDS signal strength. -
Without RDS my hardware gives me just one bit for this...
VIDEO_TUNER_RDS_ON is not available with v4l2...
Bye,
Robert
--- Begin Message ---
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
--- End Message ---
