Hi Alan Thanks for your reply ... really helped a lot >> Taking this idea further , could we also expose driver IOCTL's over >> the network ? >> >> For eg to open the cd rom drive we would be calling the following url :- > > You could but why would you make the network visible. If you look at real > clustered systems they all hide the network. You don't care where it is, > often you don't even care where the drive is. > > eject /dev/cdrom > > on such a system lets the kernel figure out who to ask to eject it. > > The job of an OS is to abstract details like that. In a clustered OS I > want to be able to type > > mount mydisk > > and I don't care who, where or how it gets mounted so long as it appears. > > Alan OK ... the idea of exposing driver ioctl 's or low level system calls or library calls over the network isn't for use in clustered systems ( although it certainly could be used there ) ... the reason I want to expose all these systems is to provide an universal interface that any programming language can request services from . To bring home the point to the Linux folks let's talk about a particular example .... Let's say you need to call an ioctl from a shell script ( I know its a very rare use case but please bear with me ... :) ) So the current way of doing it is probably to write a C program which actually calls the ioctl and then call the C program from the shell script ... However if we exposed the IOCTL as a web url we could easily call its services by using a simple utility like curl . So in our shell script we would probably write :- curl http://localhost:7000/IOCTL/IOCTL_EJECT?device=/dev/cdrom and the IOCTL_EJECT ioctl would get called on /dev/cdrom that is ioctl ( &handle_to_/dev/cdrom , IOCTL_EJECT , &some_buffer ) would get called ( by our translator running as a separate program or as a service daemon ) Taking this concept further all libraries could expose their functions via such an interface . And the benefits would go far beyond just shell scripts . Once the interface has been exposed any high level language can use the functionality provided by drivers , libraries to their full extent . If we want to expose the full power of drivers and other libraries to the entire gamut of programmers regardless of whatever language they are coding in , this could be a good way of doing it :) Thanking you , Yours sincerely , Kernel Newbie On Sat, Jan 17, 2015 at 1:07 AM, Siddhartha De <siddhartha.de87@xxxxxxxxx> wrote: > FYI ... > > > ---------- Forwarded message ---------- > From: One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx> > Date: Wed, Jan 14, 2015 at 10:03 PM > Subject: Re: Question about kernel interfaces > To: Siddhartha De <siddhartha.de87@xxxxxxxxx> > Cc: linux-kernel <linux-kernel@xxxxxxxxxxxxxxx> > > >> Just wanted to point out something :- >> >> Quoting from makelinux website :- >> http://www.makelinux.net/books/lkd2/ch17lev1sec8 >> >> "The sysfs filesystem is currently the place for implementing >> functionality previously reserved for ioctl() calls on device nodes or >> the procfs filesystem. These days, the chic thing to do is implement >> such functionality as sysfs attributes in the appropriate directory. >> For example, instead of a new ioctl() on a device node, add a sysfs >> attribute in the driver's sysfs directory. Such an approach avoids the >> type-unsafe use of obscure ioctl() arguments and the haphazard mess of >> /proc. " > > And is wrong. Certainly rather clueless people had the idea they could > make ioctl go away using sysfs, and then everyone wrote about it. Anyone > who actually thought about the problem realised immediately they are not > semantically equivalent. > >> sysfs is the new ioctl > > And as was pointed out even then they are not semantically equivalent so > everyone who was talking about "sysfs being the new ioctl" was basically > talking out the wrong end. > > What was done was to stop filling drivers with ioctls for pieces of > general information which didn't have a context attached to it or > sequence. Things like power state, what type it is, what bus it is on > etc. That avoided having zillions of ioctls but at the cost of memory. > >> Taking this idea further , could we also expose driver IOCTL's over >> the network ? >> >> For eg to open the cd rom drive we would be calling the following url :- > > You could but why would you make the network visible. If you look at real > clustered systems they all hide the network. You don't care where it is, > often you don't even care where the drive is. > > eject /dev/cdrom > > on such a system lets the kernel figure out who to ask to eject it. > > The job of an OS is to abstract details like that. In a clustered OS I > want to be able to type > > mount mydisk > > and I don't care who, where or how it gets mounted so long as it appears. > > Alan _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
