Add chardevs

[dberlin]

Hey folks, This is just a draft, in case you are interested. I have spent some time adding character device support for relays and inputs (each 8 bit group of relays/inputs appears as a single byte file).

I use this because wrapping ioctl's from various OSen gets annoying after a while, and this way requires no library at all for using relays/inputs. Only the driver is necessary.

If you are interested, i'm happy to complete support for the other boards/controls/outputs. If not, i'll keep it to myself :)

(What you see here is well tested)

[jdolanIV]

I see the write_child_apci() in apci_fops.c, and I see the apci_class_child_dev_register() calls in apci_dev.c. It's kind of hard to find changes because there's a lot of formatting changes that don't change functionality. Creating a read write interface through the files was something I had considered when designing the replacement for APCI. The functionality would vary a lot by card, and in the case of this implementation multiple files would be touching the hardware. The APCI driver started out as a side project about fifteen years ago and has just kind of grown while being maintained by several different people since then. It has a lot of issues, but it handles IRQs which is its main purpose. It also recently got a bunch of functionality added for DMA. It has competing ideas of how things should be working going on inside of it. We do expect our customers to use the libraries, and the driver mostly serves as an interface for the library with as little functionality implemented in the driver as possible. I am just starting the implementation of a replacement for APCI. I don't have any timeline for when it will be in in a usable state https://github.com/accesio/aiowdm It's main job is to allow me to write a library implementing the aiowdm API for ACCES https://accesio.com/MANUALS/Software%20Reference.pdf Most of the design changes for the driver are aimed at simplifying the layout, making it simpler to add new cards, and making use of memory mapping as much as reasonable to improve performance. If adding individual files is something good for your implementation then it seems you are well on your way, but it's not something that we are going to add to our master branch. Our designs try to put as little functionality as possible in the driver and to do the heavy work in userspace.

[dberlin]

Whoops, I wasn't paying attention to the format-on-save, sorry about that. I can fix it, but doesn't sound worth it.

As for the rest, SGTM. I totally understand. Y'all have a much better idea of who and what most of your customers need than I do :) So i'll close this.

For what it's worth: My needs are super-simple, and i'm trying to stay away from having to wrap lots of libraries into Rust just to do hardware access, for example. Especially when they are fairly simpe. So I originally wrapped the ioctl's more directly (IE rebuilt the relevant part of apcilib in rust) instead, but it's fairly unsafe code as Rust goes

• it can't really verify it's safe. It works fine, of course, and doesn't change the driver interface.

I wanted to try to keep it as safe as possible, which is why I then went the "add character device" path. Reading/writing files is safer, and also basically async and multi thread safe without meaningful work on the part of the user.

It's reasonable to say that handling analog would be hard, and that IRQ handling will always require a library, so for regular customers, they would never be able to do this. So I think your view is reasonable.

Thanks for the answer!

On Sun, Mar 19, 2023 at 11:05 PM jdolanIV @.***> wrote:

I see the write_child_apci() in apci_fops.c, and I see the apci_class_child_dev_register() calls in apci_dev.c. It's kind of hard to find changes because there's a lot of formatting changes that don't change functionality. Creating a read write interface through the files was something I had considered when designing the replacement for APCI. The functionality would vary a lot by card, and in the case of this implementation multiple files would be touching the hardware. The APCI driver started out as a side project about fifteen years ago and has just kind of grown while being maintained by several different people since then. It has a lot of issues, but it handles IRQs which is its main purpose. It also recently got a bunch of functionality added for DMA. It has competing ideas of how things should be working going on inside of it. We do expect our customers to use the libraries, and the driver mostly serves as an interface for the library with as little functionality implemented in the driver as possible. I am just starting the implementation of a replacement for APCI. I don't have any timeline for when it will be in in a usable state https://github.com/accesio/aiowdm It's main job is to allow me to write a library implementing the aiowdm API for ACCES https://accesio.com/MANUALS/Software%20Reference.pdf Most of the design changes for the driver are aimed at simplifying the layout, making it simpler to add new cards, and making use of memory mapping as much as reasonable to improve performance. If adding individual files is something good for your implementation then it seems you are well on your way, but it's not something that we are going to add to our master branch. Our designs try to put as little functionality as possible in the driver and to do the heavy work in userspace.

— Reply to this email directly, view it on GitHub https://github.com/accesio/APCI/pull/9#issuecomment-1475543793, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACPI24EH3I4TUOHO2WTIALW47CPZANCNFSM6AAAAAAV7RWJCQ . You are receiving this because you authored the thread.Message ID: @.***>