Things that Longhorn seems to be doing right
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · Joseph Pingenot
From Theodore Ts'o on Wednesday, 29 October, 2003:
Quoted 6 lines
Keep in mind that just because Windows does thing a certain way doesn't mean we have to provide the same functionality in exactly the same way.
Also keep in mind that Microsoft very deliberately blurs what they do in their "kernel" versus what they provide via system libraries (i.e., API's provided via their DLL's, or shared libraries).
Quoted 6 lines
Indeed, although certain things could be half-kernel, half-user
(OK, 0.01% kernel, 99.99% user, e.g. userspace daemon that intercepts certain writes). Of course, at that point, you might make a special library to interact with the daemon directly, although it's then not at all like just callingwrite().
I beleive this is 100% user space issue.
And I think if one really want to do something like this - Gnome's
VFS is a good candidate for this. They already have all abstractions in place.
[ Yes, sure I'm not using gnome by myself - but knowing nature of the
prokect I bet they already started doing something like this ;-))) Ashes to ashes, dust to dust - bloat to bloat. ]
Signature · 5 lines
Ihar 'Philips' Filipau / with best regards from Saarbruecken.
--
"... and for $64000 question, could you get yourself vaguely
familiar with the notion of on-topic posting?"
-- Al Viro @ LKMLQuoted 14 lines · Ihar 'Philips' Filipau
Quoted 7 lines
Quoted 6 lines
Keep in mind that just because Windows does thing a certain way doesn't mean we have to provide the same functionality in exactly the same way.
Also keep in mind that Microsoft very deliberately blurs what they do in their "kernel" versus what they provide via system libraries (i.e., API's provided via their DLL's, or shared libraries).Quoted 6 lines
Indeed, although certain things could be half-kernel, half-user
(OK, 0.01% kernel, 99.99% user, e.g. userspace daemon that intercepts certain writes). Of course, at that point, you might make a special library to interact with the daemon directly, although it's then not at all like just callingwrite().
Quoted 5 lines
I beleive this is 100% user space issue.
And I think if one really want to do something like this - Gnome's
VFS is a good candidate for this. They already have all abstractions in place.
Why not just provide a general-purpose interface for:
1. Userspace-visible transactions. A userspace process can mark a set of fd, inodes, files, or "whatever this set of processes did since now", and tell the filesystem to keep a log of changes to that. Journaling will then mark relevant changes (and possibly create an additional log depending on the design, or pass the log-related information to another userspace program), and treat them as a transaction, with the possibility of rollback on kernel-originated error, userspace request, or, possibly, a transaction manager daemon, that may have its own reason to fail the transaction.
2. Update notifications. A set of files or directories, or whatever a certain set of processes accesses, is being monitored, and the list of changes (pages, byte ranges, lists of created/deleted directory entries) is somehow maintained and being passed to a set of processes. Processes can have passive monitoring (they will know what has been changed -- good for indexers and other kinds of application-specific daemons) or intrusive pass-through monitoring (the change is not applied until the process confirms it, and transaction interface applies to this if enabled -- this will be a performance hit, and can be done for, say, a distributed transaction manager).
3. Pluggable directory generator -- a userspace process can tell the system to make an object that looks exactly like a directory, except that its contents are provided by the process, that is being queried when the directory is accessed.
Obviously, the need for performance/asyncronous access and security requirements should be addressed in the implementations of those things, however relatively small scope of the interfaces can allow to do that in a more or less sane manner. Then userspace can have all kinds of indexing monstrosities, transaction-using databases, transaction managers, etc.
Signature · 1 line
Alex
Quoted 3 lines · Alex Belits
On Thu, 30 Oct 2003, Ihar 'Philips' Filipau wrote:
...
Quoted 5 lines
3. Pluggable directory generator -- a userspace process can tell the system to make an object that looks exactly like a directory, except that its contents are provided by the process, that is being queried when the directory is accessed.
That sounds like ClearCase's dynamically generated views of directories and files.
Daniel
Signature · 2 lines
Daniel Barclay [email protected]
Quoted 6 lines · Daniel B.
Quoted 3 lines · Alex Belits
On Thu, 30 Oct 2003, Ihar 'Philips' Filipau wrote:
...
Quoted 1 line
Quoted 7 lines
Quoted 4 lines
3. Pluggable directory generator -- a userspace process can tell the system to make an object that looks exactly like a directory, except that its contents are provided by the process, that is being queried when the directory is accessed.
That sounds like ClearCase's dynamically generated views of directories and files.
Or hurd's translators.
Phil.
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · Larry McVoy
select ID,STATUS,SEVERITY,PRIORITY,SUMMARY
from bugs
where (SEVERITY == 1 or SEVERITY == 2 or SEVERITY == 3) and(PRIORITY == 1 or PRIORITY == 2 or PRIORITY == 3) and (STATUS == "new" or STATUS == "open" or STATUS == "assigned")order by
ID
In fact it mustn't be a text.
Some kind of encoding like ASN.1 will do the job. Parsing text in C - is really painful.
my 0.02 euro.
Signature · 5 lines
Ihar 'Philips' Filipau / with best regards from Saarbruecken.
--
"... and for $64000 question, could you get yourself vaguely
familiar with the notion of on-topic posting?"
-- Al Viro @ LKMLA message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Hans Reiser
All that said, the indexes themselves should just be feature enhanced directories accessed via the kernel. Feature enhancements might include such things as better space efficiency, ordering plugins, etc.
I still see no point in putting this into kernel space.
As a proof of concept - if someone wants to try - one can implement
this system on top of any other fs. in user space.
open("/aaa.txt") ->
inode ->
underlaying_fs.open(itoa(inode)+".meta")
underlaying_fs.open(itoa(inode)+".data")write(fd) -> fd<->inode -> updateindex(inode) + write(inode). [1]
and so on and so forth. LD_PRELOAD=libcoolfs.so my_cool_app
in other words file system can be used as smart storage. hard links can be 'mis'used to implement search indeces.
[1] mmap() is the notable problem.
Signature · 5 lines
Ihar 'Philips' Filipau / with best regards from Saarbruecken.
--
"... and for $64000 question, could you get yourself vaguely
familiar with the notion of on-topic posting?"
-- Al Viro @ LKML