Re: Question about kernel interfaces

[One Thousand Gnomes]

> Is sysfs 'supposed' to be a read only where various kernel parameters
> are exposed to be read ? Or are they 'supposed' to be writable too ?

You can create either

> Are all drivers in future required to expose interfaces in sysfs ?

Only if they need one (some will appear automatically as you enable power
management and the like).
 
> If the answer to the above is true , then would we be really requiring
> IOCTL calls at all anymore ... because all that we would need to do to
> make a driver do something is to change values in some of the files in
> sysfs ... for eg to call a ioctl called DO_SOMETHING on driver D1 we
> would be doing :
> 
> echo 1> /sysfs/D1/IOCTLS/DO_SOMETHING  ( or something like that ... :) )

Try implementing a few this way and you'll discover you can't. ioctls
happen on file handles which are tied to instances of an object not to
the driver. ioctl also allows read/write pairs so can be serializing and
sequenced in a way sysfs can't.

> Are there any plans of exposing the kernel api ( that is syscalls and
> libc ) as sysfs files ... for eg
> 
> echo 1> /sysfs/libc/get_system_time
> cat /sysfs/libc/results/system_time

Time is an example where you could implement it via sysfs. It's an
unusual case in that its global and stateless.

> Would it be a good idea to do this ?

No, probably not.
 
> How about exposing core system calls , libc and any new libraries over
> http/over the network  ? This would make calling ioctls and really low
> level stuff from high level languages like Java a trivial process .
> For eg right now if I wanted to call some function say foo () in
> library my_library.so in Java I would have to take the JNI/JNA route
> ... doable but not exactly 'easy' ( same for other high level
> languages ) ... whereas in the new way all I would have to do is send
> a request to say :-
>   http://localhost:7000/my_library/foo?arg1=something,arg2=something
> ( Just wanted a frank discussion on this idea .... )

Except that you've also got to transfer the data and the authentication
back and forth. You need much more than sysfs for this, you need some way
to pass messages securely, and to do work on a remote node on your
behalf. You need some way to locate a resource.

It's not entirely impossible to make syscalls remotable. It's been done to
some extent at least two ways. Read up on plan 9 (which did try and take
Unix much more networked and within the classic tradition of Unix as a
small clean OS), and perhaps also on MOSIX, which took a very different
approach to running on a cluster of boxes as one instance. Another odd
example to look at is Minix. Minix treats all syscalls internally as
messages between user processes and services like the file system. Minix
never really made use of it, but it does mean its much easier to do
remote syscall models in Minix than Linux. (in part I suspect this comes
from Tanenbaum's Amoeba and similar work).

I'm not sure I'd pick Java for this either - Java is very weak in this
area as it tends to expose notions of locality and what is and isn't
remote when doing method invocations. Languages like smalltalk on the
other hand got this right many years before.

Alan
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/