I considered this but that limits the design to 64 distinct FIFOs each being
13 chars in length. Not too bad but there will be some larger apps that will
complain and the authors will be required to patch every release. Perhaps it
would be better if you could specify parameters to the FIFO module for non
default name size and number of named FIFOs. You could make 64x13 default
and have 0x?? remove it all together.
Ciao,
John
-----Original Message-----
From: Stuart Hughes [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 07, 2000 2:01 AM
To: John VanLoon
Cc: rtlinux
Subject: Re: [rt-api] Re: [rtl] Simple API.
Hi John,
You could pre-allocated 64x13 characters in an array, which allows names
upto 12 characters per name.
Regards, Stuart
John VanLoon wrote:
>
> What would you do to accommodate the variable memory required to store the
> names?
>
> -----Original Message-----
> From: Stuart Hughes [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 06, 2000 9:16 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; realtime
> Subject: Re: [rt-api] Re: [rtl] Simple API.
>
> [EMAIL PROTECTED] wrote:
> >
> >
> > > > I was in favor of this, but now I think that that it simply repeats
in
> > > > a less portable form, open/read/write. That is, if you want raw
fifos,
> > > > use raw fifos. If you want fifos with names, use the posixio
interface
> > >
> > > The problem with the posixio in RTL is that you still have to ask for
> > > /dev/rtfx, and the x refers to an actual number, so you are not really
> >
> > How about when you register a device, you register open.close.read,write
> > and also devnumber(name)
> > Then open marches through the device table and asks if anyone has a non
-1
> > device number and then calls the device_open
> > Somewhat like ARP.
> > Thus, name resolution is left to the modules exporting devices with a
> > default mechanism for /dev/name#
> >
> > The big problem is that for fifos there needs to be some coordination
> > between file system names and RTLinux interior names.
> >
> > > much better off than the raw interface (aside from the more standard
> > > semantics). What I'm hinting at is the need for dynamic association
> > > between a name and an actual minor device number. This way we can use
> > > abstract names such as "emergency_stop" or "data_stream" and not have
it
> > > fixed to a minor device number.
> >
> > In principle, this is nice, but we need to be very careful here as this
> > gets close to a real can of worms that vanilla linux is facing now for
> > dynamic naming of devices. Because your display program
> > has one "control" fifo and the rt_com device has another and, even
worse,
> > the usb control system wants these to appear and disappear when devices
> > are hot-plugged.
> >
> > Note that under the current scheme, you can mknod
/nuclear_plant/shutdown
> > with the correct minor number and just make sure your RTtask does
> > a open("/dev/rtfXX") with the same number -- the user side has the minor
> > number hidden in the inode. Only the RT side has the number exposed.
> > And there is much to be gained by keeping this number transparent.
> > Otherwise, when the RT task does open("nuclear_plant_shutdown") and
> > the numbers are not correctly predefined or, even worse, the frank
> > program is also running and has, opened "send_frank_names_here" which
> > has the same number and so we send our nuclear plant the command
> > to "zappa" or something ...
> >
> > finally, I like the idea of having a user mode daemon provide a name
> > service if we need a name service. This takes the complex stuff out of
> > the RT kernel and puts it in user mode where it belongs. So
> > open a tcp port send a request for the filedescriptor corresponding
> > to "nuclear_power_plant_shutdown" and get one back with the daemon
taking
> > care of all coordination.
> >
> > [ Disclaimer: I do not advocate or recommend using RTLinux to
> > run nuclear power plants.]
>
> Hi Victor,
> How about a slightly different approach.
>
> - The kernel fifo module keeps track of the name/minor number
> association
> - You reserve 1 fifo for control operations (say /dev/rtf0)
> - In the kernel things proceed as normal, except you can to an
> rtf_create_named("fifoname")
> - The fifo module (driver), which maintains the name/minor number
> associations returns the next free minor number
>
> - In user space, before doing an open, you do an
> fd = rtf_getfifobyname("fifoname")
>
> this is wrapped in a header file as a macro that does:
>
> return( ioctl( open("/dev/rtf0", O_RDONLY), NAME_LOOKUP) );
>
> the kernel checks the minor number (to make sure it is the control fifo)
> and if all is okay, it returns the correct minor number that corresponds
> to the name.
> - The user space continues as normal with open(fd, O_RDONLY)
>
> The only issue is putting the name resolver in the kernel module, but I
> would argue that this is the only place where the status of the free
> channels is known. Maybe someone has an idea for a simple technique
> (simple hash ?) to maintain the name/number lookup for the 63 minor
> number ??
>
> It seems to me that this approach adds the necessary features but leaves
> the original mechanisms in place (if you don't want names, just use the
> numbers, and forget the lookup).
>
> Regards, Stuart
> --- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> ----
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/~rtlinux/
application/ms-tnef
