[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
capabilities and POSIX ``emulation''
From: |
Ivan Shmakov |
Subject: |
capabilities and POSIX ``emulation'' |
Date: |
Tue, 14 Feb 2006 23:01:41 +0600 |
Well, following is some thoughts, some of which were discussed
in the thread.
The first side of the problem with presenting multi-interface
(and multi-implementation) files to a program which uses the
POSIX layer is that such files can't be adequately represented
in the terms of POSIX. However, it's the minority of programs
that have the necessity to explore ``the true nature'' of the
file they're asked to work with (e. g. `stat'). They should be
replaced with their ``aware'' counterparts.
The second side, closely related to the first one, is that there
might be POSIX programs, which behavior depends on whether the
given path represents a file, or a directory. This problem is
very similar to the ``symbolic links vs. files they refer to''
case. The same convention (using trailing slash to distinguish
between symbolic link and the directory it points to) couldn't
be used, since there could be paths, which are symbolic link,
file and directory at the same time.
The third side of the problem is that there might be a need to
pass not only a specific interface, but the specific
implementation to the POSIX program. I'm not sure in using the
term right, but it seems that the ``capability'' passed from one
HURD process to the other could be implemented to posses a
``default view'', which the originating process could explicitly
set. Thus, the problem is in allowing POSIX programs to use the
capabilities passed to them.
Similar problem exists in passing the file descriptor from the
parent process to the child. That's no problem if it's a
standard descriptor -- 0, 1 or 2 (stdin, stdout, stderr), but
the programs commonly used aren't able to interpret any other
descriptor they get. That's how it's solved by Bash on
GNU/Linux system:
$ cat <(echo hello,) <(echo world\!)
hello,
world!
$
When interpreting <(command) construct, Bash establishes a pipe
between the command in parentheses and a child spawned for the
``outer'' command; the construct is replaced by the reference to
the file descriptor in a per-process ``file descriptors''
namespace, like /dev/fd/3:
$ echo <(echo hello,) <(echo world\!)
/dev/fd/3 /dev/fd/4
$
Of course, there're cases when this very simple solution is not
enough, e. g.:
$ emacsclient <(echo hello,\ world\!)
The problem with capabilities looks essentially the same: one
process could pass capability to a POSIX process, but the latter
won't notice, won't interpret and won't use it. So, there
should be a translator, implementing a namespace for
capabilities. This way, the method of specifying arbitrary view
of the object could be implemented by the shell, e. g. like
this:
$ touch ':(as_directory file.tar.gz)'
$ unaware-ls :(as_directory file.tar.gz)
foo
$ unaware-ls ':(as_directory file.tar.gz)'
:(as_directory file.tar.gz)
$ echo :(as_directory file.tar.gz)
/dev/caps/123
$
And no compromise -- no more characters get reserved.
Would the implemented ``capabilities namespace'' be global, the
following will also be possible, given the <(...) construct be
implemented using the capabilities as well:
$ emacsclient <(echo hello,\ world\!)
- Re: DogCows or Polymorphism in the Hurd, (continued)
- Re: DogCows or Polymorphism in the Hurd, Marcus Brinkmann, 2006/02/08
- Re: DogCows or Polymorphism in the Hurd, Patrick Negre, 2006/02/09
- Re: DogCows or Polymorphism in the Hurd, Marcus Brinkmann, 2006/02/09
- Re: DogCows or Polymorphism in the Hurd, Jonathan S. Shapiro, 2006/02/09
- Re: DogCows or Polymorphism in the Hurd, Patrick Negre, 2006/02/10
- Re: DogCows or Polymorphism in the Hurd, Jonathan S. Shapiro, 2006/02/10
- Re: DogCows or Polymorphism in the Hurd, Marcus Brinkmann, 2006/02/11
- Re: DogCows or Polymorphism in the Hurd, Ivan Shmakov, 2006/02/13
- Re: DogCows or Polymorphism in the Hurd, Marcus Brinkmann, 2006/02/14
- Re: DogCows or Polymorphism in the Hurd, Ivan Shmakov, 2006/02/14
- capabilities and POSIX ``emulation'',
Ivan Shmakov <=
- Re: DogCows or Polymorphism in the Hurd, Marcus Brinkmann, 2006/02/07
- Re: DogCows or Polymorphism in the Hurd, Patrick Negre, 2006/02/08
- Re: DogCows or Polymorphism in the Hurd, Tom Bachmann, 2006/02/08
- Re: DogCows or Polymorphism in the Hurd, Filip Brcic, 2006/02/08
- Re: DogCows or Polymorphism in the Hurd, Tom Bachmann, 2006/02/08
- Re: DogCows or Polymorphism in the Hurd, Jonathan S. Shapiro, 2006/02/08
- Re: DogCows or Polymorphism in the Hurd, Filip Brcic, 2006/02/08
- Re: DogCows or Polymorphism in the Hurd, Marcus Brinkmann, 2006/02/08
- Re: DogCows or Polymorphism in the Hurd, Jonathan S. Shapiro, 2006/02/09
- Re: DogCows or Polymorphism in the Hurd, Patrick Negre, 2006/02/08