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/
--- [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/
