Hi,
1. Will hurd still retain the symbolic link and hard link concept of
Unix/Linux?
* Also will it support hard links for directories?
* Can tranlators be symbolic linked or hard linked?
* Currently in *Nix one has to use the find command to find a list of all
symbolic links and hard links. I am wondering if this will be made much more
easier in hurd?
2. Will it support the Linux LVM concept?
3. Also what features does Hurd borrow or enhance from the Plan 9 S.
I mean for example Plan 9 abstracts everything as files. Will/does Hurd
support such concept (its sees everthing as files) or is this just
achievabal
by existing or writing custom translators?
Also Debian/Philip thanks for releasing the K14 cd's.
Thanks
Shams
Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

"S" == Shams <shams (AT) orcon (DOT) net.nzwrites:

I don't participate in GNU/Hurd development, and I don't mean my
answers to be authoritative, but

SHi, 1. Will hurd still retain the symbolic link and hard link
Sconcept of Unix/Linux?

First of all, it should be noted that there're /two/ Hurds --
one is based on GNU Mach microkernel (and there're hosts on
which GNU/Hurd system is running currently), and the other --
HurdNG, which is just being planned.

While currently available GNU/Hurd system behaves in many
respects like a GNU/Linux system (and, in fact, shares a vast
amount of source code with the latter), HurdNG differences might
be much more significant. However, my opinion is that already
developed code, when appears apt, should be used, so various
features available in UNIX or GNU/Linux should be provided as
well as the native HurdNG features. Probably, by means of PSIX
emulation layer of some sort.

S* Also will it support hard links for directories?

This problem was discussed on the list some time ago. My
opinion that it /shouldn't/ be done. If one thinks of a
directory as a mapping of file names to actual file objects, and
of hard links as the alternate names to a file (directory)
object, then it becomes hard to decide, which file (directory)
the `' name is mapped to?

S* Can tranlators be symbolic linked or hard linked?

S* Currently in *Nix one has to use the find command to find a list
Sof all symbolic links and hard links. I am wondering if this will be
Smade much more easier in hurd?

I don't understand. Using $ find command to find symbolic links
doesn't seem to be hard at all:

$ find -type s

the other hand, what do you mean by finding hard links? When
I do, e. g.:

$ touch a
$ ln a b
$

Which one I should find, `a' or `b'? From the point of UNIX,
they're completely equal and both designate the very same file.

S2. Will it support the Linux LVM concept?

Looks like with HurdNG's ``space banks'', things would be even
better than with the Linux LVM.

S3. Also what features does Hurd borrow or enhance from the Plan 9
SS. I mean for example Plan 9 abstracts everything as files.

The filesystem is itself to be implemented on top of more
general RPC interface in HurdNG. It would allow every user (or
even every program) to ``have'' it's own filesystem.

SWill/does Hurd support such concept (its sees everthing as files) or
Sis this just achievabal by existing or writing custom translators?

I think so.

SAlso Debian/Philip thanks for releasing the K14 cd's.

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

Sun, Feb 04, 2007 at 12:37:16AM +1300, Shams wrote:
Regarding HurdNG:
2. Are all Debian GNU/Hurd efforts and existing developers efforts
going to be towards HurdNG. More specifically is the current Hurd
going to be abandoned in favour of HurdNG, what is the future of this
current Hurd?

I guess this question will get evaluated once HurdNG is actually running
and installable.

3. Has the microkernel for HurdNG been chosen and if so then what
language is going to be used for HurdNG and the microkernel?

See the l4-hurd list for more information on this. HurdNG is discussed
there.

Michael

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

Hi,

Fri, Feb 02, 2007 at 12:34:16PM +1300, Shams wrote:

1. Will hurd still retain the symbolic link and hard link concept of
Unix/Linux?

Yes, the Hurd supports symlinks and hardlinks in the traditional way, as
well as an additional link type: Firmlinks.

* Also will it support hard links for directories?

The current implementation doesn't support them, but this might change.

* Can tranlators be symbolic linked or hard linked?

Sure. A translator sits on some inode, and you can always link this
inode like any other file.

* Currently in *Nix one has to use the find command to find a list of
all symbolic links and hard links. I am wondering if this will be made
much more easier in hurd?

There are no plans for anything like that.

2. Will it support the Linux LVM concept?

The Hurd allows for complex stores, which -- amongs ome other
possibilities -- can contain a concatenation of several individual
stores. This way you can use several partitions for one filesystem. I'm
not sure how Linux LVM works exactly, but I think the concept is
similar.

There is presently no complatibility with Linux LVM, but I guess it
shouldn't be too hard to implement, if someone is interested in that.

3. Also what features does Hurd borrow or enhance from the Plan 9 S.
I mean for example Plan 9 abstracts everything as files. Will/does
Hurd support such concept (its sees everthing as files) or is this
just achievabal by existing or writing custom translators?

I don't know whether it is actually borrowed (the Hurd is nearly as old
as Plan9), but the translator concept is actually quite similar to Plan9
FS servers -- both alow normal user programs to export filesystems. The
technical implementation is pretty different though, so there are a
number differences in what you can do.

The Plan9 FS servers are specifically tailored for building a system
with FS interfaces for everything. Hurd translators are not specifically
designed for that, so they might be a little less convenient for this
particular use case. (Haven't investigated the detals.) They are more
generic/powerful, on the other hand.

Not everyone likes the idea of doing everthing with standard FS
interfaces. The translator concept allows implementing any kind of
interface, not only normal filesystems. This way it is possible to have
services that are accessible through the filesystem tree, but implement
custom semantics. (Either completely new semantics, or extensions to the
standard filesystem semantics.) There are a few things in the Hurd that
make use of this possibility.
-antrik-

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

Hi,

Sat, Feb 03, 2007 at 12:49:57PM +0700, Ivan Shmakov wrote:
"S" == Shams <shams (AT) orcon (DOT) net.nzwrites:

S* Also will it support hard links for directories?

This problem was discussed on the list some time ago. My
opinion that it /shouldn't/ be done. If one thinks of a
directory as a mapping of file names to actual file objects,
and of hard links as the alternate names to a file (directory)
object, then it becomes hard to decide, which file (directory)
the `' name is mapped to?

Well, as you seem to have followed the ngHurd discussions, you should be
aware that this has shown to be only one of the reasons why having ""
links in the filesystem is a bad idea. ngHurd almost certainly won't
have these, and in fact it might be changed in the existing
implementation as well. So, this is not really a reason to avoid
hardlinks to directories.

In another discussion at a different place, someone pointed out that
hardlinked directories are problematic, because this way loops are
possible, and the filesystem would no longer be a directed graph. No
idea whether this is a serious problem in practice.

S2. Will it support the Linux LVM concept?

Looks like with HurdNG's ``space banks'', things would be even
better than with the Linux LVM.

I think the space bank concept is rather orthogonal to partitions and
LVM. Space banks are about allocating memory from the available stores,
not about how stores are laid out on HD.
-antrik-

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

Hi again,

Sun, Feb 04, 2007 at 12:37:16AM +1300, Shams wrote:

1. Now HurdNG is this going to be recognised by GNU as the official
kernel/userland or is this going to run as a separate research
project?

time will tell.

Until recently, ngHurd was discussed as a very different system, with
little likeness to the existing Hurd or UNIX concepts in general, thus
totally unsuitable as a kernel for GNU. I considered it an interesting
research project, but nothing more.

Recently however Marcus Brinkmann seems to have changed his mind, and he
now strives for something more similar and compatible with the existing
stuff, so it *might* one day replace the current implementation as the
mainline Hurd.

However, this will take at least a couple of years, so it's not really a
concern right now.

2. Are all Debian GNU/Hurd efforts and existing developers efforts
going to be towards HurdNG.

As for Debian, it's not even clear presently whether it will be possible
to port it to ngHurd at all. Depends on how much it will deviate from
traditional UNIX concepts.

More specifically is the current Hurd going to be abandoned in favour
of HurdNG, what is the future of this current Hurd?

Certainly not, at least not any time soon. ngHurd should be seen as an
experiment for now; the existing implmentation is still the mainline,
and very likely will stay so for quite some time.

IMH, development efforts should focus mostly on the existing
implementation.

3. Has the microkernel for HurdNG been chosen

No.

and if so then what language is going to be used for HurdNG and the
microkernel?

ngHurd itself will surely use C. As for the microkernel, whatever the
kernel which is chosen will use If it's decided to implement an own
one, surely it will be in C as well.

4. Regarding finding sym links and hard links. I mean currently
/usr/bin/find resorts to traversing the directory tree (which may be
timeconsuming for example traversing from the root path ("/") to find
each coressponding sym/hard link for the given directory? Couldn't
this be done somehow with i-nodes directly where the i-node that given
directory keeps records of all symlinks and hardlinks for it?

Well, the way symlinks and hardlinks are traditionaly used in UNIX, I
don't think there is much need for that.

course, one could think of applications that use links in a
bidirectional manner, e.g. for tagging. However, it's questionable
whether traditional symlinks or hardlinks are appropriate for such
applications. I have discussed this somewhat in a specific context at
.
-antrik-

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

* Also will it support hard links for directories?

The current implementation doesn't support them, but this might
change.

The current implementation does support them. Use /hurd/firmlink to
get hardlinked directories.

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

"o" == <olafBuddenhagen (AT) gmx (DOT) netwrites:

S* Also will it support hard links for directories?

ISThis problem was discussed on the list some time ago. My opinion
ISthat it /shouldn't/ be done. If one thinks of a directory as a
ISmapping of file names to actual file objects, and of hard links as
ISthe alternate names to a file (directory) object, then it becomes
IShard to decide, which file (directory) the `' name is mapped to?

oWell, as you seem to have followed the ngHurd discussions, you
oshould be aware that this has shown to be only one of the reasons
owhy having "" links in the filesystem is a bad idea. ngHurd
oalmost certainly won't have these, and in fact it might be changed
oin the existing implementation as well. So, this is not really a
oreason to avoid hardlinks to directories.

oIn another discussion at a different place, someone pointed out that
ohardlinked directories are problematic, because this way loops are
opossible, and the filesystem would no longer be a directed graph. No
oidea whether this is a serious problem in practice.

At a first glance, handling of such loops might be implemented
in applications, so the kernel could provide hardlinks to
directories with no harm. However, the ``directed graph'' model
is not just about making no loops: it demands the way to, given
some directory, obtain its parent.

Then, if a ``directory'' is thought about as a mapping of names
to files (I mean not only regular files, but directories, pipes,
etc.), then hardlinks to a directory is to be meant as a
different names to the very same directory, so, e. g.:

$ mkdir a
$ ln a b
$ cat a/file
cat: a/file: No such file or directory
$ touch a/file
$ cat a/file
$ cat b/file
$

Suppose a different scenario:

a/ $ mkdir b
a/ $ mkdir c
a/ $ ln b c/d
a/ $ cd c/d/
a/c/d/ $ cd

Which path the last command would lead to, a/c/ (as a/c/d//)
or a/ (as a/b//)?

Should `' entry be stored ``on disk'', the answer will
probably be the same every time the entry is used, bringing,
however, some confusion in how path names behave (in simple
cases, `' in path works essentially like an ``eraser'',
removing a path component to the left.)

If it's to be derived from the current working directory (in
case of `cd'), the `' sub-directories of `a/b/' and `a/c/d/'
would, indeed, be different directories. So the ``mappings''
are, actually, different. (This is how ``firmlinks''
implemented in Hurd, IIUC.)

Although I see no reason to deny such behaviour (either
``firmlinks'' or even ``no parent altogether''), my opinion is
that it's sufficiently different to ``traditional'' FS. Would
there be any uses for it? Wouldn't it make more sense to
support, e. g., some kind of a relational data model with a
separate interface?

S2. Will it support the Linux LVM concept?

ISLooks like with HurdNG's ``space banks'', things would be even
ISbetter than with the Linux LVM.

oI think the space bank concept is rather orthogonal to partitions
oand LVM. Space banks are about allocating memory from the available
ostores, not about how stores are laid out on HD.

Well, I have little knowledge of ``space banks''. I know Linux
LVM somewhat better. In simple words, LVM allows one to:

* create physical volumes out of disk partitions;

* create volume groups out of one or more physical volumes;

* allocate and deallocate memory of volume groups into logical
volumes.

From my point of view, volume group is essentially a such
``store'', from which I could allocate memory for whichever
purposes I feel appropriate (swap space, news spool,
filesystems, etc.)

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

Hi,

Sun, Feb 04, 2007 at 11:24:53AM +0100, Alfred M. Szmidt wrote:

Use /hurd/firmlink to get hardlinked directories.

Firmlinks aren't the same as hardlinks, neither technically nor
semantically.

If you have a firmlinked file or directory, then there is still a
primary (hard) link and a secondary (firm) link. Removing the primary
link will destroy the directory, breaking the firm link. With hard
links, that doesn't happen.

I think it would be useful to have a link type in the Hurd that can
fully emulate hard links in the above example (by transparently
switching the firmlink to a hard link if the primary link goes away),
but firmlink doesn't do that -- and sadly, I see some fundamental
problems, with probably make such a behaviour unfeasible :-(
-antrik-

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

Use /hurd/firmlink to get hardlinked directories.

Firmlinks aren't the same as hardlinks, neither technically nor
semantically.

If you have a firmlinked file or directory, then there is still a
primary (hard) link and a secondary (firm) link. Removing the
primary link will destroy the directory, breaking the firm
link. With hard links, that doesn't happen.

I stand corrected.

I think it would be useful to have a link type in the Hurd that can
fully emulate hard links in the above example (by transparently
switching the firmlink to a hard link if the primary link goes
away), but firmlink doesn't do that -- and sadly, I see some
fundamental problems, with probably make such a behaviour
unfeasible :-(

I see such problems as well. Do hard links even work on GNU?
could, I suppose, use a similar hack to how symlinks are handled, I
think.

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

Hi,

Tue, Feb 06, 2007 at 05:00:53PM +0100, Alfred M. Szmidt wrote:

I think it would be useful to have a link type in the Hurd that can
fully emulate hard links in the above example (by transparently
switching the firmlink to a hard link if the primary link goes
away), but firmlink doesn't do that -- and sadly, I see some
fundamental problems, with probably make such a behaviour
unfeasible :-(

I see such problems as well. Do hard links even work on GNU?

course they do. Why wouldn't they?

Problem is that they are of limited use. Hadlinks are good enough as
long as only traditional disk files are involved -- but leaving this
"safe" ground can happen very quickly, e.g. when using unionfs. Using
hardlinks (or something that behaves like hardlinks) seems much more
interesting if you can link stuff between different translators, so you
could for example move pseudo-files between translators without
explicitely copying the contents A link-unlink based move operation
allows for some interesting semantics, which seem hard to express
otherwise.

I have some ideas for a mechanism that would allow to do such
inter-translator linking, but it seems rather complicated and there are
some possible failure modes that I'm not sure how to handle sanely. All
in all, I'm not sure it's really worth the trouble. Probably I will only
find out once I start doing fancy stuff with translators

could, I suppose, use a similar hack to how symlinks are handled,
I think.

No idea what you mean :-(
-antrik-

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

I see such problems as well. Do hard links even work on GNU?

course they do. Why wouldn't they?

Was just asking.

I have some ideas for a mechanism that would allow to do such
inter-translator linking, but it seems rather complicated and there
are some possible failure modes that I'm not sure how to handle
sanely. All in all, I'm not sure it's really worth the
trouble. Probably I will only find out once I start doing fancy
stuff with translators

If you do start experimenting with this, please share the results.

could, I suppose, use a similar hack to how symlinks are
handled, I think.

No idea what you mean :-(

Ignore that, just some unprocessed thoughts on the subject.

Cheers.

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

"PT" == Pierre THIERRY <nowhere.man (AT) levallois (DOT) eu.orgwrites:

>Does this mean that something like "cd " or "ls " will no work
>in ngHurd?

PTIt would just work in the way current systems work: it's not the FS
PTbut the application that decides what is.

PTTry this on any available Unix with:

~$ mkdir -p a/b c/d
~$ cd c/d
~/c/d$ ln -s //a/b e
~/c/d$ cd e
~/c/d/e$ cd
~c/d$

PTAccording to in FS, you should now be in a/b. But currently,
PTmost shells parse lexically.

Yes, shells oftenly do that. Note, however, that almost every
other program isn't so smart:

$ mkdir -p a/b c/d
$ cd c/d
c/d $ ln -s //a/b e
c/d $ cd e
c/d/e $ ls /
b
c/d/e $

Would `ls' parse `' by itself, `e' would have been shown
instead.

And again, I'm not about to /deny/ such ``lexical''
interpretation of `', but it's not clear to me, which benefits
it would bring (or, which things it would break?)

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

"PT" == Pierre THIERRY <nowhere.man (AT) levallois (DOT) eu.orgwrites:

ISYes, shells oftenly do that. Note, however, that almost every
ISother program isn't so smart:

>$ mkdir -p a/b c/d
>$ cd c/d
>c/d $ ln -s //a/b e
>c/d $ cd e
>c/d/e $ ls /
>b
>c/d/e $

ISWould `ls' parse `' by itself, `e' would have been shown instead.

ISAnd again, I'm not about to /deny/ such ``lexical'' interpretation
ISof `', but it's not clear to me, which benefits it would bring
IS(or, which things it would break?)

PTThe benefit seems obvious to me from your example: it would make
PTsymlinks a less leaky abstraction. And I'm curious where the
PTcurrent behaviour ls exhibits here is needed.

Yet another example:

$ mkdir -p a/b a/x c/d
$ touch a/x/y
$ cd a/b
a/b $ ln -s /x z
a/b $ cd /
$ ls a/x/
y
$ ls a/b/z/
y
$

Now, let us repeat the steps from the previous example:

$ cd c/d
c/d $ ln -s //a/b e
c/d $ cd e
c/d/e $

Now, $ ls z/ will show us `y', just as expected. Would `' be
interpreted lexically, it would break the things, since
`c/d/e/z', being a symbolic link to `/x', would lead us to
non-existent `c/d/x'.

I guess, there could be some examples related to the use of GNU
Arch, since it depends on ascending directory tree recursively
to get access to its control files, `{arch}/'.

Doesn't it look like both interpretations could be useful?

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

"PT" == Pierre THIERRY <nowhere.man (AT) levallois (DOT) eu.orgwrites:

ISNow, $ ls z/ will show us `y', just as expected. Would `' be
ISinterpreted lexically, it would break the things,

PTBut you're talking about a symlink, which is precisly an
PTabstraction in the FS. That is, the application doesn't know it's
PTaccessing a symlink, so there's to interpretation of at all.

In traditional implementations, the symbolic link is, actaully,
a special kind of a file, with which a ``string'' is associated.
The ``string'' is used to do a text substritution on the
original file name, e. g., if file name is `/a/b/c', and `b'
leads to `d/e', then it's `s,a/b,a/d/e,' =`/a/d/e/c' to be
used. (The process continues recursively untill no symbolic
links in the name are left.) Note, that the ``string'' is
available to the application via readlink ().

Should symbolic links be implemented in traditional way, it
would be up to translator to readlink () and to interpret that
string.

PTWhen in a/b, and I ask a link z to /x, I'm lexically asking my
PTshell to create a link a/b/z to a/x. There is no need for the
PTsystem to keep track that it was /x at the time of it's creation,
PTAFAIK.

Are you suggesting not the string is to be stored on FS? What
else then?

If, e. g., it will be some ``direct'' reference to the file to
be stored (like device, inode pair), it would be, indeed, the
hard link. of the uses of the symbolic links is to create
``shortcut'' to some well-known location:

$ ln -s /well/known/location shortcut

Keeping the inode (and not the string) associated with the
symbolic link leaves no way to the user to create such a
``shortcut'', since the following will redirect the link to a
different file (or, the file would be the same, but the file
name the link refers to would be changed):

$ mv /well/known/location /well/known/location.old
$ mkanything /well/known/location
$

(And the problems with cross-device links will arise as well.)

Furthermore, some applications use symbolic links in rather
unusual ways. E. g., Emacs uses symbolic links for file locks
-- to store the identity of the user currently editing the file.
This, however, is easy (in idea, not in implementation) to
resolve: in Hurd, one might want to implement some new interface
rather than working with the old one such an unclear way.

ISI guess, there could be some examples related to the use of GNU
ISArch, since it depends on ascending directory tree recursively to
ISget access to its control files, `{arch}/'.

PTWould you really set up file links in a version controlled
PTdirectory hierarchy in a way that lexical directory ascending
PTwouldn't make it to the root of the working copy?

Why not? If I, e. g., need a part of the tree in some different
place for my own convenience? Doing `tla update' from that
place wouldn't be of primary importance, but nevertheless still.

ISDoesn't it look like both interpretations could be useful?

PTI'm not really convinced so far by the need of a physical entry.

It's not the physical `' entry I'm arguing the need for. I
feel, that such a ``lexical'' interpretation of `' would lead
to a sufficiently different behaviour of the programs, and the
consequences of that behaviour need to be investigated.

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

Sat, 2007-02-10 at 11:55 +0600, Ivan Shmakov wrote:
Furthermore, some applications use symbolic links in rather
unusual ways. E. g., Emacs uses symbolic links for file locks
-- to store the identity of the user currently editing the file.
This, however, is easy (in idea, not in implementation) to
resolve: in Hurd, one might want to implement some new interface
rather than working with the old one such an unclear way.

course, the only reason Emacs does this is that symlink(2) is one of
the few atomic test-and-set operations available to it which will
reliably work across a wide variety of systems.

Thomas

Help-hurd mailing list
Help-hurd (AT) gnu (DOT) org

PGP SIGNATURE
Version: GnuPG v1.4.6 (GNU/Linux)

Zkxpy8tauHtvIlWWGLqtdX0=
=FS2K
PGP SIGNATURE