|
From: Aliberti E. <ea...@us...> - 2002-04-28 07:49:27
|
It seems this one got lost at listserver switch. I resend it now.
------- Forwarded message follows -------
From: Aliberti Emanuele <ea...@us...>
To: <ros...@re...>
Subject: Re: [ros-general] Re: File system struct
Date sent: Sun, 14 Apr 2002 15:19:17 +0200
On 14 Apr 2002 at 0:11, Yuri Prokushev wrote:
> >my term virtual dir is different from a symbolic link. a virtual
> >dir doesn't exist in the FS but only in the brain of the ss
> Doesn't matter. Virtual dir - it is like doscalls.dll. Handled by
> subsystem services.
Oh, it does really matter instead!
Do not forget that what a process running in the context of an
environment subsystem CAN see is what the subsystem client library
and
server want (unless it calls the native API bypassing the host
subsystem).
For instance, "A:" is meaningful only in the W32 subsystem, because
when you type
C:\> type A:\README.TXT
KERNEL32.CreateFile("A:\README.TXT") will call internally
NTDLL.NtCreateFile("\??\A:\README.TXT")
which will be translated in
\Device\Floppy0\README.TXT
because "\??\A:" is a symbolic link in the system name space to that
device object.
For the PSX subsystem, we could define that "/dev/x" will be
translated by PSXDLL.DLL into "\POSIX+\SYSTEM\x" and PSXSS.EXE, at
initialization time, will create symbolic links in "\POSIX+\SYSTEM"
to
real devices.
That will allow a PSX process to call open("/dev/tty0") with no real
"/dev" directory on any physical volume. PSXDLL.open will translate
"/dev/tty0" in "\POSIX+\SYSTEM\tty0" which probably will be a link to
"\Device\Serial0".
------- End of forwarded message -------
|