Le 16/04/2014 09:03, Clemens Ladisch a écrit :
> Emmanuel Colbus wrote:
>> I have a question regarding vector 0x80.
>>
>> As I mentionned earlier, my OS's internals are very different from
>> Linux's, thus I have had a need for a few new syscalls. Since I
Le 16/04/2014 00:27, Theodore Ts'o a écrit :
> On Tue, Apr 15, 2014 at 11:47:56PM +0200, Emmanuel Colbus wrote:
>> My OS heavily uses chroots for security purposes (these are not true
>> Linux-like chroots, but this isn't relevant). One of the issues of
>> chroots i
Le 16/04/2014 01:34, Theodore Ts'o a écrit :
> On Wed, Apr 16, 2014 at 01:12:53AM +0200, Emmanuel Colbus wrote:
>> The solution is to use directory hardlinks. This way :
>> - applications that want to communicate through /tmp can simply specify
>> that they have a de
Le 16/04/2014 00:01, Theodore Ts'o a écrit :
> On Tue, Apr 15, 2014 at 10:53:24PM +0200, Emmanuel Colbus wrote:
>
>> The value means that the file is not a true directory, but a directory
>> hardlink. Directory hardlinks, which only appear in my ro-compatible
>>
Le 15/04/2014 22:04, Theodore Ts'o a écrit :
> On Tue, Apr 15, 2014 at 03:42:43PM +0200, Emmanuel Colbus wrote:
>> The issue is that I also needed it in other
>> partitions, including linux-created ext2 ones. Thus, I have used the
>> osd1 field for this, including in
Le 15/04/2014 22:19, Theodore Ts'o a écrit :
> On Tue, Apr 15, 2014 at 05:32:41PM +0200, Emmanuel Colbus wrote:
>>> In addition the
>>> standards and common sense together pretty much imply that you need each
>>> device to at least have a unique identifier.
>
Le 15/04/2014 22:06, Theodore Ts'o a écrit :
> On Tue, Apr 15, 2014 at 03:43:01PM +0200, Emmanuel Colbus wrote:
>> Now for something that has to do both with syscalls and filesystems...
>>
>> My operating system relies heavily upon hardlinks, and, amongst others,
&g
Le 15/04/2014 17:02, Austin S Hemmelgarn a écrit :
> On 2014-04-15 09:42, Emmanuel Colbus wrote:
>> Now, back to the filesystem...
>>
>> In order to associate devices to their files, the Linux kernel uses
>> their major and minor numbers. However, mine doesn't; inst
Le 15/04/2014 18:05, One Thousand Gnomes a écrit :
>> I think this is an unproblematic extension, especially since these
>> ioctls are only supposed to be called by low-level software shipped with
>> the OS.
>
> Thats the excuse everyone gives for messing up standards stuff. It
> usually comes bac
Le 15/04/2014 17:00, One Thousand Gnomes a écrit :
> On Tue, 15 Apr 2014 15:42:54 +0200
> Emmanuel Colbus wrote:
>
>> Continuing with syscalls, I would like to indicate you a modification
>> I've done with regards to ioctl's. The thing is, I have had the need f
Le 15/04/2014 17:10, One Thousand Gnomes a écrit :
>> Also, for your information, I decided to use 64-bit capabilities, in
>> order to give a possibility to reduce the rights of an unprivileged
>> software (for example, if a process lacks CAP_USR_CHMOD, it won't be
>> able to perform a chmod on an
Le 15/04/2014 17:06, One Thousand Gnomes a écrit :
>> In order to associate devices to their files, the Linux kernel uses
>> their major and minor numbers. However, mine doesn't; instead, I've
>> attributed myself a single group of values (major=0, minor=0, for both
>> character-mode and block-mode
Le 15/04/2014 17:02, One Thousand Gnomes a écrit :
> On Tue, 15 Apr 2014 15:42:51 +0200
> Emmanuel Colbus wrote:
>
>> Continuing the discussion regarding syscalls, I have a question
>> regarding vector 0x80.
>>
>> As I mentionned earlier, my OS's intern
Now, a second suggestion : in /proc, besides the pids and the /proc/self
symlink, there are several files that have a length of 0 (according to
stat(2)), but actually have a non-empty content. What about making these
files character-mode device files? I mean, a file whose content is
virtual an whos
Now for something that has to do both with syscalls and filesystems...
My operating system relies heavily upon hardlinks, and, amongst others,
directory hardlinks. (Yes, that's what my ext2l partitions are for. Not
only, but this is part of it).
To allow distinguishing them from true directories,
Now, another question. In ext2, what is the point of the dtime field?
Personaly, I'm never setting it, because, well, if an inode is removed,
it's removed, and nobody is supposed to access it again; and anyways,
since no syscall allows seeing it, the dtime seems to me like nothing
but an informatio
fer not to); just tell me about it.
Thank you for your attention!
Emmanuel Colbus
P.S. : I read LKML through hypermail, so you don't need to keep me CC'd,
but if you do, please keep the [MANUX] tag in the subject, otherwise my
antispam will reject your mail.
--
To unsubscribe from this lis
With regards to the adaptations I've made, the most notable ones apply
to ext2. Here are the choices I've done :
- I've attributed myself identifier 5 as creator OS in the superblock.
Is it okay? (The os-dependant fields currently have the same
interpretation as under Linux, but I have still chose
Finally, since cloning the Linux kernel gave me some ideas, I would like
to give you a couple of suggestions of my own. Feel free to do what you
want with them.
First, I'm not sure whether this has been done or not, but I would like
to suggest you to mark your kernel memory allocator with gcc's ma
Now another syscall. I recently implemented capabilities, and decided to
use a version number that's different from the one Linux uses. I guess
that's exactly how I should have done it, but can you confirm me that
this is acceptable?
Also, for your information, I decided to use 64-bit capabilitie
Now, I would like to ask you a few questions about some stuff I've not
fully understood. Let's start with the d_off field in the dirent
structure of the getdents(2) and getdents64(2) syscalls. What is its
meaning?
Personnaly, I've implemented it as documented in the manpage, but
since it doesn't s
Continuing the discussion regarding syscalls, I have a question
regarding vector 0x80.
As I mentionned earlier, my OS's internals are very different from
Linux's, thus I have had a need for a few new syscalls. Since I wanted
to avoid any collision with Linux, but I also wanted to keep the
ability
Now, I would like to discuss syscalls.
As my kernel is binarily compatible with Linux, it implements the same
syscalls on the same vector (0x80, I've not yet implemented
sysenter-like things, and as mentionned earlier, it currently only
runs on x86/32). Of course, not all of them have been reimple
Continuing with syscalls, I would like to indicate you a modification
I've done with regards to ioctl's. The thing is, I have had the need for
ioctl's that return *file descriptors*, instead of standard return codes.
To distinguish them from the others, I have given them identifiers that
are super
Now, back to the filesystem...
In order to associate devices to their files, the Linux kernel uses
their major and minor numbers. However, mine doesn't; instead, I've
attributed myself a single group of values (major=0, minor=0, for both
character-mode and block-mode special files), with the meani
25 matches
Mail list logo
