I/O Drivers

J

Thread Starter

Jiri Baum

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
 
D
Hi Jiri,

> 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.

Hmm, I think we may just be arguing terminology. A wrapper around /dev/ttyS0 isn't a driver in the Linux sense.

> Most people would probably prefer not to mess around in the kernel if they can help it...
>

More evidence that we don't disagree that much. If it isn't in the kernel, it almost certainly isn't a Linux driver. It may well still be a vital hardware support program for the PLC...


> 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.

I wasn't saying that we should write kernel mode drivers where we don't need to. That would be rather dumb. I was just saying that kernel mode drivers should present the standard Linux driver interface. You seem to be saying that most "drivers" don't need to be kernel mode so it doesn't matter. I agree. OK?

I'll try to remember that we mean different things by the term,

dan

_______________________________________________
LinuxPLC mailing list
[email protected]linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc
 
Hello,

Dan Pierson:
> I wasn't saying that we should write kernel mode drivers where we don't
> need to. That would be rather dumb. I was just saying that kernel mode
> drivers should present the standard Linux driver interface. You seem to
> be saying that most "drivers" don't need to be kernel mode so it doesn't
> matter. I agree. OK?

OK. Seems we don't disagree at all, I was just a bit careless with terminology.

> I'll try to remember that we mean different things by the term,

Do you think it's worth it to use a different term?

Or, to turn the question around: can you think of a term that would be better to use?


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
 
D
Hi Ron

Need to check up on my Linux theology... There are definitely multiple layers of drivers in the Linux kernel; take the file system layers for
example. But you can talk to any of these with the standard system calls (e.g. open("/dev/sda8") opens block device that contains my root partition; open("/") opens my root directory, which is on that partition). Is a user mode library that you use to talk to IO via a different set of interfaces a driver? Well, yes it is in a sense.

But I can't open() it, etc. so it doesn't quote act like one. This means that commands and scripts that can sometimes be used for debugging normal driver IO can't be used for debugging your ABEthernet Library ('cat' is the simplest example). Does that mean that your library isn't a driver?

Maybe I've been too restrictive in my definitions.

dan


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi Jiri:

Of course we'd use userland programs for serial and TCP/IP stuff. But properly dealing with permissions for hardware from userland can be
difficult to do securely. Anything that needs interrupts will need to be in kernel space. Agree that devices are going to be a lot of work. I
already have a "conventional" driver for 8255, If I don't break it, I don't have to maintain it. We want to use as many "standard" drivers as we
can simply for the work factor. The drivers we build should be "standard" drivers for others to use to save them work. I would prefer to stick to
Ethernet I/O, serial I/O and simple cards, but it is imperative that we try to support an array of fieldbusses. Those cards often have coprocessors and lots of messy details that may or may not fit the norm anyway. Now a question, where do the protocols live?

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Hello,

please note that much of this thread was generated by a terminology clash rather than any real disagreement.

Curt Wuollet:
> Of course we'd use userland programs for serial and TCP/IP stuff.

Yup.

> But properly dealing with permissions for hardware from userland can be
> difficult to do securely.

True, but compiling the thing into the kernel isn't really `securely' either; it just bypasses all security - which you can do from userland too
(somewhat more selectively).

> Anything that needs interrupts will need to be in kernel space.

Yes.

> Agree that devices are going to be a lot of work. I already have a
> "conventional" driver for 8255, If I don't break it, I don't have to
> maintain it. We want to use as many "standard" drivers as we can simply
> for the work factor.

True. But then again writing the wrapper for the 8255 device will probably be not all that much less work than writing a userland 8255 driver... (And configuring a userland driver may be easier for the end-user.)

> I would prefer to stick to Ethernet I/O, serial I/O and simple cards, but
> it is imperative that we try to support an array of fieldbusses.

Of course. Though I suspect that the simpler cards will be supported well before the messy fieldbusses.


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
 
Top