Thomas B. O'Hanlan:
> > It seems that specifying a standard API for doing I/O would alleviate
> > some concerns. Maybe speed is the issue.

Curt Wuollet:
> That's what we are attempting to work out with this example. We have two
> votes for using the standard char driver API and Jiri thinks a userland
> driver would be just as easy.

I just don't see the point of going to the complication of a kernel driver when a userland process is sufficient...

Where a kernel driver is necessary (eg for interrupts) or already exists, sure, use it; but for the 8255 it seems like a lot of code for little effect. Surely a few inb()/outb() calls would suffice?

(And it's not just code - the installation complexity for a kernel driver is much higher, too, because it must be compiled alongside the kernel; all a user-land process needs is suid root. Quality must be better, because a kernel driver can stuff up much more than even an IO-privileged process. Fewer people are competent in compiling, inserting and configuring kernel
drivers than compiling and running programs.)

> We may do it both ways and see. One API for serial, direct attached,
> ethernet and fieldbus I/O would be great but I doubt it's practical
> unless you want to consider the interface to the mm an API.

The mm interface doesn't do any `configuration' type stuff (though the Great Namer was intended to do that, eventually).

In any case, we are going to need configuration stuff for other parts of the linuxPLC (logic engines, HMIs, PIDs, whatever), and all of those will be userland. An userland I/O process would seem to be just more of the same.

> There's more than one interface on some types as they need to be set up
> in ways that we don't want to do with the MM and there are other "out of
> band" functions. The char driver handles these with ioctl() calls. There
> won't be any for some types.

In any case, there will be a userland process which calls those ioctl()s. At that stage, it can simply take note of the stuff itself rather than
passing it on.

Again, please don't consider this `a vote against kernel drivers'. Consider it `a vote against gratuituous kernel drivers'.


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

 

Jiri Baum wrote:

> I just don't see the point of going to the complication of a kernel driver
> when a userland process is sufficient...
>
> Where a kernel driver is necessary (eg for interrupts) or already exists,
> sure, use it; but for the 8255 it seems like a lot of code for little
> effect. Surely a few inb()/outb() calls would suffice?
>
> (And it's not just code - the installation complexity for a kernel driver
> is much higher, too, because it must be compiled alongside the kernel; all
> a user-land process needs is suid root. Quality must be better, because a
> kernel driver can stuff up much more than even an IO-privileged process.
> Fewer people are competent in compiling, inserting and configuring kernel
> drivers than compiling and running programs.)

This is not entirely a technical question. It is UNIX tradition to adhere to the philosophy. It is also one of the community goals. If we would
make Linux a viable platform for automation and control, we should make an effort to make our work reusable by others. One of the big
roadblocks to using Linux for automation and control is the lack of drivers for I/O. There is some value in a userland scheme as an example, but it's harder to reuse than a "standard" driver. We owe that much to the kernel developers and countless others that gave
us Linux. It's really only an issue with boards, but, seeing a host of automation hardware drivers in the kernel distribution would start a lot of Linux automation projects. I'm not advocating that we pervert everything to look like a char driver. But we must have an interface se we can use drivers that are available and we write
drivers that others can use. Well written drivers don't need any putzing, they can even be loaded on demand.

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

 

Could we put this entire discussion at a later stage? It sounds to me as it actually is too early to really make anything useful out of this discussion. I think a reference I/O userland process and a reference I/O kernel driver both up and running targeting 8255 would be a good start, after that I think this entire discussion will die by itself since everyone realizes both ways exist and are working and the next step is up to the one actually implementing the I/O for each
particular board...


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------


-----Original Message-----
From: MIME :[email protected] [SMTP:MIME :[email protected]]

Jiri Baum wrote:

> Thomas B. O'Hanlan:
> > > It seems that specifying a standard API for doing I/O would alleviate
> > > some concerns. Maybe speed is the issue.
>
> Curt Wuollet:
> > That's what we are attempting to work out with this example. We have two
> > votes for using the standard char driver API and Jiri thinks a userland
> > driver would be just as easy.
>
...
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Hello,

Curt Wuollet:
> If we would make Linux a viable platform for automation and control, we
> should make an effort to make our work reusable by others.

True.

> One of the big roadblocks to using Linux for automation and control is
> the lack of drivers for I/O.

But - for our purposes - it doesn't matter what kind of driver it is as long as it works with the linuxPLC.

> There is some value in a userland scheme as an example, but it's harder
> to reuse than a "standard" driver. We owe that much to the kernel
> developers and countless others that gave us Linux.

Then again, if we write a userland driver, it won't take a kernel hacker very long to convert it. Certainly much less than it'll take one of us to write a kernel driver.

> I'm not advocating that we pervert everything to look like a char
> driver. But we must have an interface se we can use drivers that are
> available and we write drivers that others can use.

Of course. Things that already exist as char drivers, or that can be naturally thought of as char drivers, should go in the kernel. I just can't see how an average digital I/O board could be thought of as a character stream...

> Well written drivers don't need any putzing, they can even be loaded on
> demand.

Well, yes, but I'm not sure how many on the list are up to producing well-written kernel drivers. I'm not, for one.

If we have expert kernel hackers working with us, then sure, make things kernel drivers. But I don't see any in the Maintainers file, and for the
average programmer it is better to write ordinary processes which are easier to compile, run, kill and debug, and when they crash, they only bring down themselves.

> > Again, please don't consider this `a vote against kernel drivers'.
> > Consider it `a vote against gratuituous kernel drivers'.

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

 

[email protected]:
...
> everyone realizes both ways exist and are working and the next step is up
> to the one actually implementing the I/O for each particular board...

Agreed.

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

 

Hello,

Curt Wuollet:
> If we would make Linux a viable platform for automation and control, we
> should make an effort to make our work reusable by others.

True.

> One of the big roadblocks to using Linux for automation and control is
> the lack of drivers for I/O.

But - for our purposes - it doesn't matter what kind of driver it is as long as it works with the linuxPLC.

> There is some value in a userland scheme as an example, but it's harder
> to reuse than a "standard" driver. We owe that much to the kernel
> developers and countless others that gave us Linux.

Then again, if we write a userland driver, it won't take a kernel hacker very long to convert it. Certainly much less than it'll take one of us to write a kernel driver.

> I'm not advocating that we pervert everything to look like a char
> driver. But we must have an interface se we can use drivers that are
> available and we write drivers that others can use.

Of course. Things that already exist as char drivers, or that can be naturally thought of as char drivers, should go in the kernel. I just can't see how an average digital I/O board could be thought of as a character stream...

> Well written drivers don't need any putzing, they can even be loaded on
> demand.

Well, yes, but I'm not sure how many on the list are up to producing well-written kernel drivers. I'm not, for one.

If we have expert kernel hackers working with us, then sure, make things kernel drivers. But I don't see any in the Maintainers file, and for the
average programmer it is better to write ordinary processes which are easier to compile, run, kill and debug, and when they crash, they only bring down themselves.

> > Again, please don't consider this `a vote against kernel drivers'.
> > Consider it `a vote against gratuituous kernel drivers'.

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