On Tue, 14 Oct 2008, Matt Craighead wrote:
Another alternative is to use some sort of out-of-band communication
with the server (socket, shared memory, etc). Doesn't suffer from
either of the above issues and does not have the limitations and
implementation problems (having to access another process's address
space directly) of ioctls.
OTOH if you can solve it with standard file operations within the same
namespace as the regular files, that's the best solution. Like you
said you get network transparency, and you also let normal tools
operate on the special control files, which can be a very powerful
thing (think scripting). You'd never get that with ioctls, and that's
one of the reasons why ioctls suck.
Miklos
--
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Hiten Pandya | Re: up? (emacs docbook xml ide) |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
git: | |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Daniel Eischen | Re: error with thread |
