Re: [ros-kernel] Re: File system struct

[KJK::Hyperion <no...@li...>]

At 03.47 01/05/2002, you wrote:
>>>As for implementing /proc in the posix subsystem vs. the kernel, why 
>>>should it be implemented in the kernel if it is only going to be seen by 
>>>the posix subsystem?
>>because it's a filesystem. Why don't you implement named pipes and 
>>mailslots in user mode inside kernel32 and csrss? what's the difference?
>ALL subsystems, and native applications see named pipes and mailslots, 
>even kernel mode drivers. They don't see /proc, only posix apps do, that's 
>the difference.

Frankly, I don't understand what does that demonstrate. If you implement 
/dev and /proc as devices with special filesystems attached, you'll have 
objects like \Device\Proc, \Device\Dev, \FileSystem\Proc and \FileSystem\Dev

>>And I don't want to explain yet another time why /proc and /dev should be 
>>visible to all subsystems. Let's just say they could all benefit from it. 
>>Just like they should all benefit from NT security, Windows device 
>>management (try, just for fun, to read a floppy disk under any Unix - try 
>>Solaris for added fun), DDI drivers, etc.
>/dev CAN't be visible to anything but posix applications, because only 
>posix applications have any concept of what /dev is.

Most of them don't. They receive /dev paths as parameters and open that 
stuff like they would open files

>Win32 apps only understand that devices are files with special names, such 
>as COM1, and native apps understand that they are device objects in the 
>\Devices directory.  A posix /dev directory contains device nodes, which 
>do not exist in the NT kernel, and therefore, the kernel can not export to 
>user mode.

if /dev has its own filesystem, I don't see why it can't do device nodes 
and whatnot

>While the /dev and /proc directories themselves can not be directly 
>visible to native and win32 apps, some equivalents can be.  For instance, 
>/dev/null is seen by win32 as the NUL device.  /dev/fd0 is seen as 
>\\.\Floppy0, and so on.  On the other hand, you talked about it being 
>useful for a win32 app to have access to /proc/pid/fd/0 to read from 
>stdin, but this simply can not be done, because NT and win32 have no 
>concept of file descriptors.

I expected this answer. You forget that handles for stdin, stdout and 
stderr (file numbers 0, 1 and 2, as explicitely defined by the standard) 
are easily accessible from other processes, since they have a well-known 
location, based on the PEB. Non-POSIX processes will only have 
/proc/pid/fd/0, 1 and 2, ok? However, there's more to /proc than just file 
descriptors

Of course, /proc digs inside the kernel, so we shouldn't be too worried to 
match the Linux /proc structure exactly

>>I think I already explained this:
>>  1. introduce a new file information class (FilePosixInformation) for 
>> attributes common to all Unix filesystems (owner, primary group, access 
>> bitmask, file type bits). File attributes specific to some filesystems 
>> (sparse, immutable, append-only, compressed, etc.) will be retrieved and 
>> set through NtFsControlFile()
>This is the sort of kludge/compromise that I was talking about.  If this 
>were done, then posix apps and native/win32 apps would not see the files 
>in the same way.

Clarification: FilePosixInformation is primarily intended for Unix 
filesystems (Ext2, Ext3, Reiser, etc.). Other filesystems need not 
implement it, in such cases it's the subsystem's responsibility to decide 
what to do: return an error, or reconstruct the information by mixing other 
information classes

>Another problem is what if someone does an mknod() to create a device 
>node?  What does win32 see this file as?  Just a useless 0 byte file?  Or 
>would win32 be able to somehow open the device node, and get a real device?

Device nodes are still an open issue, but more generically special files 
(sockets, pipes, etc.) will be handled by the filesystem

>>  3.2. Windows app accessing Unix filesystem. File attributes are 
>> translated into the nearest equivalents (file name beginning with dot -> 
>> hidden, ext2 immutable attribute -> read-only, etc.). Access masks are 
>> translated into the equivalent ACLs and viceversa. But, if an ACL cannot 
>> be translated into an access mask, an error is returned. The biggest 
>> problem is that there's no reliable way to translate from user ids and 
>> group ids to SIDs. It could be implemented by extending the LSA, but is 
>> it worth it? The solution is simple: don't use Unix filesystems. Support 
>> them for compatibility only. And implement special filesystems, like 
>> /proc, /dev, but also named pipes and mailslots, with NT security semantics
>We aren't running on a posix filesystem, we are running on an NT 
>filesystem.  If you want to emulate win32 on posix, then that's what WINE 
>is for, the goal of ReactOS is to provide an actual NT system.  I for one 
>certainly don't want to give up ACLs.

It's exactly what I meant. If NT security cannot be implemented over Unix 
filesystems, fine, they'll have no security (but the only limit is the 
translation between uids/gids and SIDs...)