L'enorme delai que prend l'integration de ReiserFS 4 dans le noyau officiel vient du fait que le code est tres intrusif. Bref, c'est plus qu'un module, comme le dit Rik van Riel :
The reiser 4 system call sys_reiserfs seems to need an additional patch, which is craftily hidden inside reiser4-only.patch. That patch creates fs/reiser4/linux-5_reiser4_syscall.patch, which I can only assume reiser 4 users should apply...
Kind of ugly.
Looking further, the horrors only increase. It looks like sys_reiser4() is an interface to load programs into the kernel, with reiserfs4 containing an interpreter.
I'll leave aside the issues of having a scripting language inside the kernel, since I'm sure other people will comment on it. However, I am absolutely flabbergasted that Hans Reiser is using a syscall here, instead of a filesystem interface.
Furthermore, why do the parsing in the kernel, instead of compiling the human-readable strings in userspace and loading something easy to use into the kernel, like the selinux subsystem does?
Since this code is bound to be horribly controversial, it may be an idea to remove this from the reiserfs4 core patch. That way the battles over the filesystem, and its interactions with the rest of the kernel can be fought first, without having the whole reiserfs4 filesystem strand in the quicksand of "why do we need an interpreted language with completely new filesystem semantics in the kernel?
Il faut que le developpement de ReiserFS change un peu de direction pour qu'il soit integre au kernel.
[^] # Re: Toujours pas de reiser4 !
Posté par Jérôme Pinot (site web personnel) . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 10.
The reiser 4 system call sys_reiserfs seems to need an additional patch, which is craftily hidden inside reiser4-only.patch. That patch creates fs/reiser4/linux-5_reiser4_syscall.patch, which I can only assume reiser 4 users should apply...
Kind of ugly.
Looking further, the horrors only increase. It looks like sys_reiser4() is an interface to load programs into the kernel, with reiserfs4 containing an interpreter.
I'll leave aside the issues of having a scripting language inside the kernel, since I'm sure other people will comment on it. However, I am absolutely flabbergasted that Hans Reiser is using a syscall here, instead of a filesystem interface.
Furthermore, why do the parsing in the kernel, instead of compiling the human-readable strings in userspace and loading something easy to use into the kernel, like the selinux subsystem does?
Since this code is bound to be horribly controversial, it may be an idea to remove this from the reiserfs4 core patch. That way the battles over the filesystem, and its interactions with the rest of the kernel can be fought first, without having the whole reiserfs4 filesystem strand in the quicksand of "why do we need an interpreted language with completely new filesystem semantics in the kernel?
Il faut que le developpement de ReiserFS change un peu de direction pour qu'il soit integre au kernel.