linux-kernel - Re: Question about kernel interfaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20150114163317.46a1ecec@lxorguk.ukuu.org.uk>
Date:	Wed, 14 Jan 2015 16:33:17 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Siddhartha De <siddhartha.de87@...il.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Question about kernel interfaces

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/