User-agent: MacSOUP/D-2.5 (Mac OS X version 10.3.9)
Drwe, Godfrey, thanks.
So it look like I found at least a part of the way.
Andrew Gallatin <email@hidden> wrote:
> Hado Hein writes:
> > I want to implement a device interfacing api in /dev that is already
> > done in linux.
>
> Bear in mind that the BSD /dev interface does not provide you with
> any easy way to keep track of per-open information. Eg, there
> is no file_ptr->private_data.
>
> The only easy way to do this is to have a whole slew of minors, allow
> only one open per minor, and to lookup your per-open information based
> on the minor number.
Short said I have these lighting devices that repeatedly transmit 512
bytes. There are three or four config calls to the device. But the
amount rises averagely to 200kBit/s per device.
So merely I'll go for a block device and have some ioctls that are done
in the usb drivers open/close. Since I know that usually only the data
is read.
I like to ask ongoing :
The other side would be
a) an USB interface
b) a network socket
I'm doing this from scratch since nothing really appropiate is findable.
Is it more senseful to do two different kexts that implement their
devnodes - or doing one devfs kext and to (data source) kexts that
communicate to the devfs kext ?
In a) I'd assign devnodes in the drivers open/close so that private data
of the devnode can be stored somewhere in the private data of the USB
DeviceInterface. This would always be one node per device rwrwr- .
For b) I'm somewhat stuck at the moment. This is quite a problem since I
could receive the data on the socket in userland. But I need to give it
out on a devnode like the others. With some time constraints.
Regardless of where I receive that (ArtNet protocol) data I have
traffic; Since for every sender (avg 4) I need to buffer 3 secs of data
for (avg 40) 256 indexed pages. (4*((512b*30Hz)*40Pg*3sec)=~230KB)=~1M
and some calcs and RLE to do over this data.
The idea the linux guy had was that for stage lighting userland apps
should have one api to access their special hardware. While the windoze
party always does dlls that an userland programmer has to include into
their own code.
Later there came up the same thing over ethernet.
If there is an already existing place for developers to give out a known
api like devfs to users(land) that hides implementation details of
hardware (ethernet, usb, and one company that uses firewire) at a quite
high data rate I'd bear to know it.
thanks for the help,
Hado
P.S. DMX4Linux on sourceforge if you're interested on stage lighting
control
--
Hado Hein, Berlin, Fed.Rep. of Germany
Talk about it ? AIM: chat2hado
http://www.batchmaker.de (software authoring, including stage lighting)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-drivers/email@hidden
This email sent to email@hidden