On Thursday 22 January 2004 19:54, Greg KH wrote: > On Wed, Jan 21, 2004 at 07:31:57PM +0100, Frank.A.Uepping@t-online.de wrote: > > Ok, here is what I want to achieve. > > > > I am working on a remote-CAPI implementation for Linux. > > https://sourceforge.net/projects/rcapi4linux/ > > Currently I am porting/rewriting to kernel-2.6. > > > > The new (for kernel-2.6) remote-CAPI implementation should introduce a > > new service allowing other code/modules to register/drive a remote-CAPI > > controller. Basically, a remote-CAPI controller is a CAPI controller with > > additional capabilities suited to facilitate the implementation of > > various remote-CAPI solutions. A remote CAPI controller is a pure > > software device, no physical hardware is involved here! > > So a remote CAPI controller is on the current system, right? Yes. A remote CAPI ctr (more precisely the code that registered/drive that controller) is in someway interconnected (most likely TCP) with a physical ISDN controller on the remote host. > How does it talk to the physical hardware on a different machine? > What does it use to do the communication? Since I want to dissociate the way a remote CAPI controller is used (policy) from the pure mechanism that it provides, it is not responsible for this; actually, the code that registers a remote controller is responsible for this. However, this all is theory and not implemented yet! I think, it will be better first to provide/write some code before we continue here. Thank you Greg for your assistance so far. > > Does it bind to a specific network interface? If so, there's your > parent in the sysfs tree :) > > > In order to make various information (like the registered controllers, > > its state, its CAPI applications, etc) available to the user I have > > chosen to use the sysfs for this (when this is appropriate at all). > > Here is a sample tree: > > > > /sys/.../rcapi/ > > > > |-- ctr0 > > | > > | |-- manufacturer > > | |-- serial_number > > | |-- state > > | |-- debug > > | |-- appl0/ > > | | > > | | |--- state > > | | |--- remote_id > > | | |--- id > > | | > > | |-- appl1/ > > | | > > | | |--- state > > | | |--- ... > > | > > |-- ctr1/ > > | > > | |-- manufacturer > > > > ... > > > > My questions are: > > Is the sysfs appropriate for this kind of usage? > > Yes. Ok; so I am not completely wrong with my thoughts... The problem that I see with the sysfs is that it is dedicated to hardware related issues, apparently; and pure software abstractions (e.g. virtual hardware) are currently not really fit here in. > > greg k-h /FAU -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
