One of these centuries we must replace the present keyboard
and console stuff, probably by something very similar to
Vojtech's input device stuff, and we must make sure that
the new code is powerful enough to last for a few years again.
Why only something similar to the input suite and not
People want to read the last sector on a disk, but our present
code does not easily allow that, since size checking is done
in units of 1024 bytes, not in units of 512 bytes.
We have seen very ugly solutions ("add an ioctl to read the last sector")
and very kludgy solutions ("create a partition
People want to read the last sector on a disk, but our present
code does not easily allow that, since size checking is done
in units of 1024 bytes, not in units of 512 bytes.
We have seen very ugly solutions (add an ioctl to read the last sector)
and very kludgy solutions (create a partition
Now that I asked in public for manpages for the not-yet-documented
system calls, I suppose I should report on received pages in order
to avoid duplication. Yesterday or so I got an madvise.2 page
and polished it a bit. Current version below. Comments are welcome.
Note that comments in
Now that I asked in public for manpages for the not-yet-documented
system calls, I suppose I should report on received pages in order
to avoid duplication. Yesterday or so I got an madvise.2 page
and polished it a bit. Current version below. Comments are welcome.
Note that comments in
New: man-pages 1.38, with for the first time over 1000 pages.
Undocumented system calls include:
rt_sigreturn, rt_sigaction, rt_sigprocmask, rt_sigpending,
rt_sigtimedwait, rt_sigqueueinfo, rt_sigsuspend,
sigaltstack, getpmsg, putpmsg, ugetrlimit, mmap2,
madvise.
Contributions are
New: man-pages 1.38, with for the first time over 1000 pages.
Undocumented system calls include:
rt_sigreturn, rt_sigaction, rt_sigprocmask, rt_sigpending,
rt_sigtimedwait, rt_sigqueueinfo, rt_sigsuspend,
sigaltstack, getpmsg, putpmsg, ugetrlimit, mmap2,
madvise.
Contributions are
> I wonder if the Configure.help text should not possibly be even _more_
> distributed than just splitting it up into different files. It might very
> well be acceptable to actually distribute it over the net (and have just
> a mapping of config options into www-addresses or something).
I think
From: [EMAIL PROTECTED]
We just had a problem when running some formatting-utils on
a large amount of disks synchronously: We got a NULL-pointer
violation when accessig blk_size[major] for our major number.
Further research showed, that grok_partitions was running at
that
From: [EMAIL PROTECTED]
We just had a problem when running some formatting-utils on
a large amount of disks synchronously: We got a NULL-pointer
violation when accessig blk_size[major] for our major number.
Further research showed, that grok_partitions was running at
that
I wonder if the Configure.help text should not possibly be even _more_
distributed than just splitting it up into different files. It might very
well be acceptable to actually distribute it over the net (and have just
a mapping of config options into www-addresses or something).
I think this
Recently I reported for 2.4.3 and 2.4.5 a failure to detect
a USB CF card reader caused by the occurrence of a Unit Attention
at boot time. An ugly solution is to remove this "error" in
usb/storage/transport.c, but since this is perfectly normal
SCSI behaviour, and can in principle occur with all
Recently I reported for 2.4.3 and 2.4.5 a failure to detect
a USB CF card reader caused by the occurrence of a Unit Attention
at boot time. An ugly solution is to remove this error in
usb/storage/transport.c, but since this is perfectly normal
SCSI behaviour, and can in principle occur with all
>> [things work better when "Unit Attention: not ready to ready transition"
>> is not regarded as an error]
> I suggest trying this with 2.4.5 -- several people report that kernel
> works much better than previous ones with usb-storage.
The details of the behaviour are a bit different, but the
> Current interface had grown an impressive collection of warts.
> Worse yet, you _can't_ put parsing into generic code.
> There are filesystems that have a binary object as 'data'.
Yes, that was a very unfortunate decision, back in the good old times
when nfs was implemented. And smb, ncp, coda
From [EMAIL PROTECTED] Sun Jun 3 13:25:31 2001
> [One could start a subdiscussion about that part.
> The mount(2) system call needs to transport vfs information
> and per-fs information. So far, the vfs information used
> flag bits only, but sooner or later we'll want to
> We can kludge around anything. The question being, what for?
> It still leaves ncp with its ioctls ugliness.
I show how to simplify the kernel source without changing the
interface. That is good, and there are some free benefits.
You want to design a new interface. Maybe that is good as well,
We can kludge around anything. The question being, what for?
It still leaves ncp with its ioctls ugliness.
I show how to simplify the kernel source without changing the
interface. That is good, and there are some free benefits.
You want to design a new interface. Maybe that is good as well,
From [EMAIL PROTECTED] Sun Jun 3 13:25:31 2001
[One could start a subdiscussion about that part.
The mount(2) system call needs to transport vfs information
and per-fs information. So far, the vfs information used
flag bits only, but sooner or later we'll want to have
Current interface had grown an impressive collection of warts.
Worse yet, you _can't_ put parsing into generic code.
There are filesystems that have a binary object as 'data'.
Yes, that was a very unfortunate decision, back in the good old times
when nfs was implemented. And smb, ncp, coda
[things work better when Unit Attention: not ready to ready transition
is not regarded as an error]
I suggest trying this with 2.4.5 -- several people report that kernel
works much better than previous ones with usb-storage.
The details of the behaviour are a bit different, but the essence
>> /* No capabilities? What if users do thousands of these? */
> look at mount_is_safe()
Yes, good. My remark means that more tests are required
than those sketched in mount_is_safe(), and that means
that for the time being we can throw out the routine
mount_is_safe(), and remove the test on
From [EMAIL PROTECTED] Sun Jun 3 02:49:08 2001
On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote:
> This evening I needed to work on a filesystem of a non-Linux OS,
> full of absolute symlinks. After mounting the fs on /mnt, each
> symlink pointing to /foo/bar in that filesystem
From [EMAIL PROTECTED] Sun Jun 3 02:49:08 2001
On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote:
This evening I needed to work on a filesystem of a non-Linux OS,
full of absolute symlinks. After mounting the fs on /mnt, each
symlink pointing to /foo/bar in that filesystem
/* No capabilities? What if users do thousands of these? */
look at mount_is_safe()
Yes, good. My remark means that more tests are required
than those sketched in mount_is_safe(), and that means
that for the time being we can throw out the routine
mount_is_safe(), and remove the test on
This evening I needed to work on a filesystem of a non-Linux OS,
full of absolute symlinks. After mounting the fs on /mnt, each
symlink pointing to /foo/bar in that filesystem should be
regarded as pointing to /mnt/foo/bar.
Since doing ls -ld on every component of every pathname was
far too
My RTL8139 (Identified 8139 chip type 'RTL-8139A')
was fine in 2.4.3 and doesnt work in 2.4.5.
Copying the 2.4.3 version of 8139too.c makes things work again.
Since lots of people complained about this, I have not tried to
debug - maybe a fixed version already exists?
One remark:
2.4.5 says
Compiling 2.4.5 with CONFIG_USB=y and CONFIG_PCI not set
fails with drivers/usb/usbdrv.o: undefined reference to `pci_pool_*'.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Compiling 2.4.5 with CONFIG_USB=y and CONFIG_PCI not set
fails with drivers/usb/usbdrv.o: undefined reference to `pci_pool_*'.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
My RTL8139 (Identified 8139 chip type 'RTL-8139A')
was fine in 2.4.3 and doesnt work in 2.4.5.
Copying the 2.4.3 version of 8139too.c makes things work again.
Since lots of people complained about this, I have not tried to
debug - maybe a fixed version already exists?
One remark:
2.4.5 says
This evening I needed to work on a filesystem of a non-Linux OS,
full of absolute symlinks. After mounting the fs on /mnt, each
symlink pointing to /foo/bar in that filesystem should be
regarded as pointing to /mnt/foo/bar.
Since doing ls -ld on every component of every pathname was
far too
> So how does this say the value of the fdsets are undefined
> after a timeout?
You are right, it doesn't say so. I should have said
That is, a wise programmer does not assume any particular value
for the bits after an error.
Andries
-
To unsubscribe from this list: send the line
On Tue, 29 May 2001, John Chris Wren wrote:
> In BSD, select() states that when a time out occurs,
> the bits passed to select will not be altered.
> In Linux, which claims BSD compliancy for this
> in the man page (but does not state either way
>
On Tue, 29 May 2001, John Chris Wren wrote:
In BSD, select() states that when a time out occurs,
the bits passed to select will not be altered.
In Linux, which claims BSD compliancy for this
in the man page (but does not state either way
what
So how does this say the value of the fdsets are undefined
after a timeout?
You are right, it doesn't say so. I should have said
That is, a wise programmer does not assume any particular value
for the bits after an error.
Andries
-
To unsubscribe from this list: send the line unsubscribe
> Besides, just on general principles, we'd better have clean interface
> for changing partitioning
It is not quite clear to me what you are arguing for or against.
But never mind - I'll leave few hours from now.
When the time is there I'll show you an implementation,
and if you don't like it,
> Andries, initrd code is _sick_.
Oh, but the fact that there exists a bad implementation
does not mean the idea is wrong. It is really easy to
make an elegant implementation.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
> But I don't want an initrd.
Don't be afraid of words. You wouldnt notice - it would do its
job and disappear just like piggyback today.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From [EMAIL PROTECTED] Wed May 23 14:16:46 2001
> It is entirely possible to remove all partition table handling code
> from the kernel. User space can figure out where the partitions
> are supposed to be and tell the kernel.
> For the initial boot this user space can be in
Alan writes:
The current partitioning code consists of re-reading from disk. That is
code that has to be present anyway even without an initrd since it is
needed for mounting other filesystems
I am not quite sure what you are saying here.
(For example, the "even" was unexpected.)
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
>
> > why not implement partitions as simply doing block remaps
>
> Everybody agrees.
No they don't.
We had this discussion already. We all agree.
Maybe you read in "remap" something other than a simple addition
but I don't.
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
why not implement partitions as simply doing block remaps
Everybody agrees.
No they don't.
We had this discussion already. We all agree.
Maybe you read in remap something other than a simple addition
but I don't. This
But I don't want an initrd.
Don't be afraid of words. You wouldnt notice - it would do its
job and disappear just like piggyback today.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Andries, initrd code is _sick_.
Oh, but the fact that there exists a bad implementation
does not mean the idea is wrong. It is really easy to
make an elegant implementation.
Andries
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Besides, just on general principles, we'd better have clean interface
for changing partitioning
It is not quite clear to me what you are arguing for or against.
But never mind - I'll leave few hours from now.
When the time is there I'll show you an implementation,
and if you don't like it,
Alan writes:
The current partitioning code consists of re-reading from disk. That is
code that has to be present anyway even without an initrd since it is
needed for mounting other filesystems
I am not quite sure what you are saying here.
(For example, the even was unexpected.)
It
From [EMAIL PROTECTED] Wed May 23 14:16:46 2001
It is entirely possible to remove all partition table handling code
from the kernel. User space can figure out where the partitions
are supposed to be and tell the kernel.
For the initial boot this user space can be in an
>> dev_t rdev;
> Reasonable.
Good. We all agree.
(But now you see what I meant in comments about mknod.)
>> kdev_t dev;
> Useless. If you hope that block_device will help to solve rmmod races
Yes. Why am I mistaken?
Andries
-
To unsubscribe from this list: send the line
> IMHO it would be nice to create wrappers for accessing the block arrays
Last year Linus didnt like that at all. Maybe this year.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
> why not implement partitions as simply doing block remaps
Everybody agrees.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
From [EMAIL PROTECTED] Wed May 23 00:39:23 2001
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
>
> The operations are different, but all bdev/cdev code is identical.
>
> So the choice is between two uglies:
> (i) have some not entirely trivial amount of code twice in
Martin Dalecki writes:
> Erm... I wasn't talking about the DESIRED state of affairs!
> I was talking about the CURRENT state of affairs. OK?
Oh, but in 1995 it was quite possible to compile the kernel
with kdev_t a pointer type, and I have done it several times since.
The kernel keeps growing,
Martin Dalecki writes:
> I fully agree with you.
Good.
Unfortunately I do not fully agree with you.
> Most of the places where there kernel is passing kdev_t
> would be entierly satisfied with only the knowlendge of
> the minor number.
My kdev_t is a pointer to a structure with device data
> They are entirely different. Too different sets of operations.
Maybe you didnt understand what I meant.
both bdev and cdev take care of the correspondence
device number <---> struct with operations.
The operations are different, but all bdev/cdev code is identical.
So the choice is between
Alexander Viro writes:
> patch below adds the missing half of kdev_t -
> for block devices we already have a unique pointer
> and that adds a similar animal for character devices.
Very good.
(Of course I did precisely the same, but am a bit slower in
submitting things during a stable series or
Linus writes:
0 is EOF _for_reads_. For writes it is not very well defined
Hmm.
So -EFBIG is certainly the preferable return value,
Yes. The Austin 6th draft writes
EFBIG:
An attempt was made to write a file that exceeds the implementation-defined
maximum file size or the
>> What is the communication between user space and kernel
>> that transports device identities?
> It doesn't change, the same symbolic names still work.
But today, unless you think of devfs or so, device identities
are not transported by symbolic names. They are given by
device numbers.
[Yes,
Linus writes:
0 is EOF _for_reads_. For writes it is not very well defined
Hmm.
So -EFBIG is certainly the preferable return value,
Yes. The Austin 6th draft writes
EFBIG:
An attempt was made to write a file that exceeds the implementation-defined
maximum file size or the
Alexander Viro writes:
patch below adds the missing half of kdev_t -
for block devices we already have a unique pointer
and that adds a similar animal for character devices.
Very good.
(Of course I did precisely the same, but am a bit slower in
submitting things during a stable series or
They are entirely different. Too different sets of operations.
Maybe you didnt understand what I meant.
both bdev and cdev take care of the correspondence
device number --- struct with operations.
The operations are different, but all bdev/cdev code is identical.
So the choice is between two
Martin Dalecki writes:
I fully agree with you.
Good.
Unfortunately I do not fully agree with you.
Most of the places where there kernel is passing kdev_t
would be entierly satisfied with only the knowlendge of
the minor number.
My kdev_t is a pointer to a structure with device data
and
From [EMAIL PROTECTED] Wed May 23 00:39:23 2001
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
The operations are different, but all bdev/cdev code is identical.
So the choice is between two uglies:
(i) have some not entirely trivial amount of code twice in the
why not implement partitions as simply doing block remaps
Everybody agrees.
Andries
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
IMHO it would be nice to create wrappers for accessing the block arrays
Last year Linus didnt like that at all. Maybe this year.
Andries
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
dev_t rdev;
Reasonable.
Good. We all agree.
(But now you see what I meant in comments about mknod.)
kdev_t dev;
Useless. If you hope that block_device will help to solve rmmod races
Yes. Why am I mistaken?
Andries
-
To unsubscribe from this list: send the line unsubscribe
What is the communication between user space and kernel
that transports device identities?
It doesn't change, the same symbolic names still work.
But today, unless you think of devfs or so, device identities
are not transported by symbolic names. They are given by
device numbers.
[Yes,
How about:
# mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap
# ls /dev/mypartition
basesizedevicetype
Generally, we shouldn't care which order the kernel enumerates
devices in or which device number gets assigned internally. If we
did
How about:
# mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap
# ls /dev/mypartition
basesizedevicetype
Generally, we shouldn't care which order the kernel enumerates
devices in or which device number gets assigned internally. If we
did
After man-pages-1.36 and kbd-1.06 today util-linux-2.11c.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> Andries, I wouldn't call it trivial.
I am a mathematician. Definition of trivial in this case:
"No intelligence required, just patience and careful work".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
> Getting a list of all ioctls in the tree, along with types of their arguments
> would be a great start. Anyone willing to help with that?
% man 2 ioctl_list
gives a very outdated list. Collecting the present list is trivial
but time-consuming. If anyone does I would be happy if he also
sent
Getting a list of all ioctls in the tree, along with types of their arguments
would be a great start. Anyone willing to help with that?
% man 2 ioctl_list
gives a very outdated list. Collecting the present list is trivial
but time-consuming. If anyone does I would be happy if he also
sent me
Andries, I wouldn't call it trivial.
I am a mathematician. Definition of trivial in this case:
No intelligence required, just patience and careful work.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
After man-pages-1.36 and kbd-1.06 today util-linux-2.11c.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> root@bug:/zip# mount /zip
> root@bug:/zip# ls -al
> total 8
> drwxr-xr-x2 root root 4096 Dec 1 08:29 .
> drwxr-xr-x 31 65534root 4096 Apr 24 20:56 ..
> root@bug:/zip# cd /zip
> root@bug:/zip# ls -al
> total 22182
> ...
> Is that okay?
Yes. Your working directory
From [EMAIL PROTECTED] Sat May 19 20:07:23 2001
> > initrd is an unnecessary pain in the ass for most people.
> > It had better not become mandatory.
>
> You would not notice the difference, only your kernel would be
> a bit smaller and the RRPART ioctl disappears.
> initrd is an unnecessary pain in the ass for most people.
> It had better not become mandatory.
You would not notice the difference, only your kernel would be
a bit smaller and the RRPART ioctl disappears.
[Besides: we have lived with DOS-type partition tables for ten years,
but they will not
> What are the units of the return value of the BLKGETSIZE ioctl on Linux?
Sectors of size 512.
> or is it in units of sector size bytes as returned by BLKSSZGET
No.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
>> Opening device files often has interesting side effects.
> Too bad. They can be triggered by similar races between attacker
> changing the type of object (file<->symlink) and backup.
Yes. This is a well-known security problem.
Doing
stat("file", );
if (action desired) {
Alexander Viro writes:
> Folks, before you get all excited about cramming side effects
> into open(2), consider ...
I agree completely.
> A lot of stuff relies on the fact that close(open(foo, O_RDONLY))
> is a no-op. Breaking that assumption is a Bad Thing(tm).
Also here I would like to
Andrew Morton writes:
> > (2) what about bootstrapping? how do you find the root device?
> > Do you do "root=/dev/hda/offset=63,limit=1235823"? Bit nasty.
>
> Ben's patch makes initrd mandatory.
Can this be fixed? I've *never* had to futz with initrd.
Probably most
From: Ben LaHaise <[EMAIL PROTECTED]>
3. Userspace partition code proposal
Given the above two bits, here's a brief explaination of a
proposal to move management of the partitioning scheme into
userspace, along with portions of raid startup, lvm, uuid and
What are the units of the return value of the BLKGETSIZE ioctl on Linux?
Sectors of size 512.
or is it in units of sector size bytes as returned by BLKSSZGET
No.
Andries
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
root@bug:/zip# mount /zip
root@bug:/zip# ls -al
total 8
drwxr-xr-x2 root root 4096 Dec 1 08:29 .
drwxr-xr-x 31 65534root 4096 Apr 24 20:56 ..
root@bug:/zip# cd /zip
root@bug:/zip# ls -al
total 22182
...
Is that okay?
Yes. Your working directory does not
From: Ben LaHaise [EMAIL PROTECTED]
3. Userspace partition code proposal
Given the above two bits, here's a brief explaination of a
proposal to move management of the partitioning scheme into
userspace, along with portions of raid startup, lvm, uuid and
Andrew Morton writes:
(2) what about bootstrapping? how do you find the root device?
Do you do root=/dev/hda/offset=63,limit=1235823? Bit nasty.
Ben's patch makes initrd mandatory.
Can this be fixed? I've *never* had to futz with initrd.
Probably most systems
Alexander Viro writes:
Folks, before you get all excited about cramming side effects
into open(2), consider ...
I agree completely.
A lot of stuff relies on the fact that close(open(foo, O_RDONLY))
is a no-op. Breaking that assumption is a Bad Thing(tm).
Also here I would like to agree.
From [EMAIL PROTECTED] Sat May 19 20:07:23 2001
initrd is an unnecessary pain in the ass for most people.
It had better not become mandatory.
You would not notice the difference, only your kernel would be
a bit smaller and the RRPART ioctl disappears.
Would I
Opening device files often has interesting side effects.
Too bad. They can be triggered by similar races between attacker
changing the type of object (file-symlink) and backup.
Yes. This is a well-known security problem.
Doing
stat(file, s);
if (action desired) {
initrd is an unnecessary pain in the ass for most people.
It had better not become mandatory.
You would not notice the difference, only your kernel would be
a bit smaller and the RRPART ioctl disappears.
[Besides: we have lived with DOS-type partition tables for ten years,
but they will not
> IMO that's the case of POSIX being misapplied. Rationale:
> * historically, ...
Yes, I know all about that.
Nevertheless the facts are here:
EPERM The system does not allow unlinking of directories,
or unlinking of directories requires privileges
that
Someone complained a moment ago about the error return in unlink.
And indeed, it used to be correct but since 2.1.132 we return a
buggy (or at least non-POSIX) error for unlink(directory).
Just changed the man page to say
unlink(2)
...
EPERM The system does not allow unlinking of
> I disagree that the kernel should apply sequence numbers
You did not read my text. I do not propose the kernel should.
(Quite the contrary, in fact.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
I disagree that the kernel should apply sequence numbers
You did not read my text. I do not propose the kernel should.
(Quite the contrary, in fact.)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Someone complained a moment ago about the error return in unlink.
And indeed, it used to be correct but since 2.1.132 we return a
buggy (or at least non-POSIX) error for unlink(directory).
Just changed the man page to say
unlink(2)
...
EPERM The system does not allow unlinking of
IMO that's the case of POSIX being misapplied. Rationale:
* historically, ...
Yes, I know all about that.
Nevertheless the facts are here:
EPERM The system does not allow unlinking of directories,
or unlinking of directories requires privileges
that
The LANANA discussion has forked into a forest of vaguely related
discussions. If I am not mistaken the only real question is
how user space and kernel space communicate device identities.
Here "user space" is very different from "users".
Devices have a device path and device contents.
For the
The LANANA discussion has forked into a forest of vaguely related
discussions. If I am not mistaken the only real question is
how user space and kernel space communicate device identities.
Here user space is very different from users.
Devices have a device path and device contents.
For the
> Im very interested in 32bit dev_t or at least implementing
> the 'lots of majors' half of it because we are probably
> going to need it in the 2.5 years before we have a 2.6
Yes, a larger dev_t has been desirable for a long time,
and more and more kludges are invented to work around its lack.
>> The exercise is essentially the patch that I sent last month or so.
> mknod takes a 32bit input
> the stat64 padding only has room for 32bits
Hmm. You make me search for this old patch.
Since Linus' reaction was not exactly positive I left
the topic again, but there must be a copy
201 - 300 of 737 matches
Mail list logo
