J
Hello,
Dan Pierson:
> I put "drivers" in quotes above because I think that Jiri and I have a
> fairly serious disagreement here: IMHO it would be a big mistake to write
> an actual IO driver that did not conform to the standard Linux/Unix
> driver interface (i.e. open(), close(), read(), write(), ioctl(), etc.).
OK, seems that we do - I didn't realize (or else I forgot).
I think we should accept drivers of either kind.
Especially if the device can be accessed by existing means (serial port, Ethernet), there's no point putting stuff in the kernel. Effectively then the `driver' would just be a wrapper around /dev/ttyS0.
I suspect implementing a device may well end up being the bulk of the work.
> Recent versions of RTLinux even support the preceeding subset in real
> time code. Deviating from this standard will:
> 1. Limit the driver strictly to this project.
I don't see this as a serious problem. (The source is there, anyway, if someone wants to make something else of it.) I'd imagine most of the
drivers would be little use for anything else, anyway.
> 2. Confuse experienced Linux programmers.
Most people would probably prefer not to mess around in the kernel if they can help it...
> 3. Make it harder for this project to use existing drivers.
Not at all - if a driver exists, either write a wrapper or change its interface, whichever is easier.
> 4. Make acceptance of the resulting code much less likely in the Linux
> community.
I don't see why (or why we should care). As long as the code uses the appropriate access methods (inb(2) and outb(2), or use /dev/port) I don't
see anything wrong with it.
> This means that a "driver" that does direct IO to the smm is not a driver
> in the Linux sense,
No, it isn't, it's a `linuxPLC I/O driver'.
> but a higher level wrapper around a driver. Such a wrapper is obviously
> a reasonable thing to write. If I was doing this I'd write one (IO) or
> two (I and O) table driven tasks that wrapped standard Linux interface
> drivers. It appears that Jiri would rather write a wrapper for each
> driver. Either approach could work.
Actually, I'd favour writing most drivers as native linuxPLC.
Really, putting the I/O drivers in the kernel is going to be a lot of work; sure, some boards will need it, but the bulk of them are just 8255 chips.
I'm not convinced the benefits justify the work.
For serial-port devices, there's even less point.
Jiri
--
Jiri Baum <[email protected]
Windows is not popular. Windows is *widespread*. Linux is popular.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
Dan Pierson:
> I put "drivers" in quotes above because I think that Jiri and I have a
> fairly serious disagreement here: IMHO it would be a big mistake to write
> an actual IO driver that did not conform to the standard Linux/Unix
> driver interface (i.e. open(), close(), read(), write(), ioctl(), etc.).
OK, seems that we do - I didn't realize (or else I forgot).
I think we should accept drivers of either kind.
Especially if the device can be accessed by existing means (serial port, Ethernet), there's no point putting stuff in the kernel. Effectively then the `driver' would just be a wrapper around /dev/ttyS0.
I suspect implementing a device may well end up being the bulk of the work.
> Recent versions of RTLinux even support the preceeding subset in real
> time code. Deviating from this standard will:
> 1. Limit the driver strictly to this project.
I don't see this as a serious problem. (The source is there, anyway, if someone wants to make something else of it.) I'd imagine most of the
drivers would be little use for anything else, anyway.
> 2. Confuse experienced Linux programmers.
Most people would probably prefer not to mess around in the kernel if they can help it...
> 3. Make it harder for this project to use existing drivers.
Not at all - if a driver exists, either write a wrapper or change its interface, whichever is easier.
> 4. Make acceptance of the resulting code much less likely in the Linux
> community.
I don't see why (or why we should care). As long as the code uses the appropriate access methods (inb(2) and outb(2), or use /dev/port) I don't
see anything wrong with it.
> This means that a "driver" that does direct IO to the smm is not a driver
> in the Linux sense,
No, it isn't, it's a `linuxPLC I/O driver'.
> but a higher level wrapper around a driver. Such a wrapper is obviously
> a reasonable thing to write. If I was doing this I'd write one (IO) or
> two (I and O) table driven tasks that wrapped standard Linux interface
> drivers. It appears that Jiri would rather write a wrapper for each
> driver. Either approach could work.
Actually, I'd favour writing most drivers as native linuxPLC.
Really, putting the I/O drivers in the kernel is going to be a lot of work; sure, some boards will need it, but the bulk of them are just 8255 chips.
I'm not convinced the benefits justify the work.
For serial-port devices, there's even less point.
Jiri
--
Jiri Baum <[email protected]
Windows is not popular. Windows is *widespread*. Linux is popular.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc