>> 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,
On Tue, 22 May 2001, Jan Harkes wrote:
>
> something like,
>
> ssize_t kioctl(int fd, int type, int cmd, void *inbuf, size_t inlen,
> void *outbuf, size_t outlen);
>
> As far as functionality and errors it works like read/write in a single
> call, pretty much what Richard
> > Thats a bit pathetic. So I have to fill my app with expensive pthread locks
> > or hack all the drivers and totally change the multi-open sematics in the ABI
> huh?
For the sound. And remember each open of /dev/audio is a different channel
potentially (ie its a factory)
-
To unsubscribe from
On Tue, May 22, 2001 at 04:31:37PM +0100, Alan Cox wrote:
> > `the class of devices in question' was cryptographic devices, and possibly
> > other transactional DSPs. I don't consider audio to be transactional.
> > in any case, you can do transactional things with two threads, as long
> > as they
> `the class of devices in question' was cryptographic devices, and possibly
> other transactional DSPs. I don't consider audio to be transactional.
> in any case, you can do transactional things with two threads, as long
> as they each have their own fd on the device. Think of the fd as your
>
On Mon, 21 May 2001, Alexander Viro wrote:
> On Mon, 21 May 2001, Linus Torvalds wrote:
>
> > It shouldn't be impossible to do the same thing to ioctl numbers. Nastier,
> > yes. No question about it. But we don't necessarily have to redesign the
> > whole approach - we only want to re-design the
On Tue, May 22, 2001 at 08:49:04AM +0100, Alan Cox wrote:
> > For _devices_, though? I don't expect my mouse to work if gpm and xfree
> > both try to consume device events from the same filp. Heck, it doesn't
> > even work when they try to consume events from the same inode :-) I think
> > this
On Monday 21 May 2001 14:43, [EMAIL PROTECTED] wrote:
> 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 o
On Monday 21 May 2001 10:14, Lars Marowsky-Bree wrote:
> On 2001-05-19T16:25:47,
>
>Daniel Phillips <[EMAIL PROTECTED]> said:
> > How about:
> >
> > # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap
> > # ls /dev/mypartition
> > base sizedevice type
> > # cat /dev/my
On Mon, May 21, 2001 at 03:10:32PM -0700, Linus Torvalds wrote:
> That, in turn, might be as simple as changing the ioctl incoming arguments
> of into a structure like .
At least make sure that the 'kioctl' returns the number of bytes placed
into the output buffer, as userspace doesn't necessari
> For _devices_, though? I don't expect my mouse to work if gpm and xfree
> both try to consume device events from the same filp. Heck, it doesn't
> even work when they try to consume events from the same inode :-) I think
> this is a reasonable restriction for the class of devices in question.
Alexander Viro writes:
> drivers/net/ppp_generic.c:
> ppp_set_compress(struct ppp *ppp, unsigned long arg)
> {
[snip]
> if (copy_from_user(&data, (void *) arg, sizeof(data))
> || (data.length <= CCP_MAX_OPTION_LENGTH
> && copy_from_user(ccp_option, data.ptr, da
On Tue, May 22, 2001 at 02:22:34AM +0200, Ingo Oeser wrote:
> ioctl has actually 4 semantics:
>
> command only
> command + read
> command + write
> command + rw-transaction
>
> Separating these would be a first step. And yes, I consider each
> of them useful.
>
> command only: reset drive
echo
On Mon, May 21, 2001 at 06:13:18PM -0700, Linus Torvalds wrote:
> Nope. You can (and people do, quite often) share filps. So you can't
> associate state with it.
For _devices_, though? I don't expect my mouse to work if gpm and xfree
both try to consume device events from the same filp. Heck, i
On Tue, 22 May 2001, Matthew Wilcox wrote:
>
> > command + rw-transaction: "dear device please mangle this data"
> >(crypto processors come to mind...)
>
> I can't think of a reasonable tool-based approach to this, but I can
> definitely see that a program could use this well. It simply req
On Mon, 21 May 2001, Linus Torvalds wrote:
> It shouldn't be impossible to do the same thing to ioctl numbers. Nastier,
> yes. No question about it. But we don't necessarily have to redesign the
> whole approach - we only want to re-design the internal kernel interfaces.
>
> That, in turn, mig
On Mon, 21 May 2001, Alan Cox wrote:
>
> > Sure. But we have to do two syscalls only if ioctl has both in- and out-
> > arguments that way. Moreover, we are talking about non-trivial in- arguments.
> > How many of these are in hotspots?
>
> There is also a second question. How do you ensure the
> Sure. But we have to do two syscalls only if ioctl has both in- and out-
> arguments that way. Moreover, we are talking about non-trivial in- arguments.
> How many of these are in hotspots?
There is also a second question. How do you ensure the read is for the right
data when you are sharing a
> Which, BTW, is a wonderful reason for having multiple channels. Instead
> of write(fd, "critical_command", 8); read(fd,); you read from the right fd.
> Opened before you enter the hotspot. Less overhead than ioctl() would
> have...
The ioctl is one syscall, the read/write pair are two. Im n
On Mon, 21 May 2001, Alan Cox wrote:
> > > I don't need to read it. Don't be insulting. Sure, you *can* use a
> > > write(2)/read(2) cycle. But that's two syscalls compared to one with
> > > ioctl(2) or transaction(2). That can matter to some applications.
> >
> > I just don't think so. Where
> > I don't need to read it. Don't be insulting. Sure, you *can* use a
> > write(2)/read(2) cycle. But that's two syscalls compared to one with
> > ioctl(2) or transaction(2). That can matter to some applications.
>
> I just don't think so. Where did you see performance-critical use of
> ioctl()?
Hi!
> > > The transaction(2) syscall can be just as easily abused as ioctl(2) in
> > > this respect. People can pass pointers to ill-designed structures very
> >
> > Right. Moreover, it's not needed. The same functionality can be
> > trivially implemented by write() and read(). As the matter of
Hi!
> > Now that I'm awake and refreshed, yeah, that's awful. But
> > echo "hot-add,slot=5,device=/dev/sda" >/dev/md0/control *is* sane. Heck,
> > the system can even send back result codes that way.
>
> Only to an English speaker. I suspect Quebec City canadians would prefer a
> different com
[EMAIL PROTECTED] (Linus Torvalds) wrote on 20.05.01 in
<[EMAIL PROTECTED]>:
> If we had nice infrastructure to make ioctl's more palatable, we could
> probably make do even with the current binary-number interfaces, simply
> because people would use the infrastructure without ever even _seeing
On Sun, May 20, 2001 at 12:02:35PM -0700, Linus Torvalds wrote:
> The problem with ioctl's is, let me repeat, not technology.
>
> It's people.
>
> ioctl's are a way to do ugly things. That's what they have ALWAYS been.
> And because of that, people don't care about following the rules - if
> ioc
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 need
On 2001-05-19T16:25:47,
Daniel Phillips <[EMAIL PROTECTED]> said:
> How about:
>
> # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap
> # ls /dev/mypartition
> basesizedevice type
> # cat /dev/mypartition/size
> 1048576
> # cat /dev/mypartition/device
> /dev
On Saturday 19 May 2001 08:23, Ben LaHaise wrote:
> /dev/sda/offset=1024,limit=2048
> -> open a device that gives a view of sda at an
> offset of 1KB to 2KB
Whatever we end up with, can we express it in terms of base, size,
please?
--
Daniel
-
To unsubscrib
On Mon, 21 May 2001, Ingo Molnar wrote:
>
> On Sun, 20 May 2001, Alexander Viro wrote:
>
> > Linus, as much as I'd like to agree with you, you are hopeless
> > optimist. 90% of drivers contain code written by stupid gits.
>
> 90% of drivers contain code written by people who do driver developm
From: "Alexander Viro" <[EMAIL PROTECTED]>
> On Sun, 20 May 2001, Paul Fulghum wrote:
> > I'll be the first to admit there is some ugliness in my driver.
>
> So will anyone here regarding his or her code. Count me in, BTW.
>
> Could you reread the posting you are refering to?
Sorry if I misunders
On Sun, 20 May 2001, Paul Fulghum wrote:
> I'll be the first to admit there is some ugliness in my driver.
So will anyone here regarding his or her code. Count me in, BTW.
Could you reread the posting you are refering to?
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
On Mon, 21 May 2001, Ingo Molnar wrote:
>
> On Sun, 20 May 2001, Alexander Viro wrote:
>
> > Linus, as much as I'd like to agree with you, you are hopeless
> > optimist. 90% of drivers contain code written by stupid gits.
>
> 90% of drivers contain code written by people who do driver develo
>> 90% of drivers contain code written by stupid gits.
>
> From: "Alan Cox"
> I think thats a very arrogant and very mistaken view of the problem. 90%
> of the driver are written by people who are
>
> - Copying from other drivers
> - Using the existing API's to make their job easy
> - Working to
On Sun, 20 May 2001, Alexander Viro wrote:
> Linus, as much as I'd like to agree with you, you are hopeless
> optimist. 90% of drivers contain code written by stupid gits.
90% of drivers contain code written by people who do driver development in
their spare time, with limited resources, most o
On Sun, 20 May 2001, Alan Cox wrote:
> > Linus, as much as I'd like to agree with you, you are hopeless optimist.
> > 90% of drivers contain code written by stupid gits.
^^^
>
> I think thats a very arrogant and very mistaken view of the problem. 90%
> of the driver are
> Linus, as much as I'd like to agree with you, you are hopeless optimist.
> 90% of drivers contain code written by stupid gits.
I think thats a very arrogant and very mistaken view of the problem. 90%
of the driver are written by people who are
- Copying from other drivers
[EMAIL PROTECTED] said:
> Now, a good way to force the issue may be to just remove the "ioctl"
> function pointer from the file operations structure altogether. We
> don't have to force peopel to use "read/write" - we can just make it
> clear that ioctl's _have_ to be wrapped, and that the only i
On Sun, 20 May 2001, Linus Torvalds wrote:
> No, but the point is, everybody _would_ consider it a bug if a
> low-level driver "write()" did anything but touched the explicit buffer.
>
> Code like that would not pass through anybody's yuck-o-meter. People would
> point fingers and say "That is
Davem, check the last thing, please.
On Sun, 20 May 2001, Alexander Viro wrote:
>
> On Sun, 20 May 2001, Linus Torvalds wrote:
>
> > > How about moratorium on new ioctls in the meanwhile? Whatever we do in
> > > fs/ioctl.c, it _will_ take time.
> >
> > Ehh.. Telling people "don't do that" sim
On Sun, 20 May 2001, Alexander Viro wrote:
>
> On Sun, 20 May 2001, Matthew Wilcox wrote:
>
> > On Sun, May 20, 2001 at 03:11:53PM -0400, Alexander Viro wrote:
> > > Pheeew... Could you spell "about megabyte of stuff in ioctl.c"?
> >
> > No.
> >
> > $ ls -l arch/*/kernel/ioctl32*.c
> > -rw-r-
On Sun, 20 May 2001, Linus Torvalds wrote:
> > How about moratorium on new ioctls in the meanwhile? Whatever we do in
> > fs/ioctl.c, it _will_ take time.
>
> Ehh.. Telling people "don't do that" simply doesn't work. Not if they can
> do it easily anyway. Things really don't get fixed unless p
On Sun, 20 May 2001, Alexander Viro wrote:
>
> Pheeew... Could you spell "about megabyte of stuff in ioctl.c"?
I agree. But it would certainly force people to think about this. And it
may turn out that a lot of it can be streamlined, and not that much ends
up being used very much.
It would als
On Sun, 20 May 2001, Matthew Wilcox wrote:
> On Sun, May 20, 2001 at 03:11:53PM -0400, Alexander Viro wrote:
> > Pheeew... Could you spell "about megabyte of stuff in ioctl.c"?
>
> No.
>
> $ ls -l arch/*/kernel/ioctl32*.c
> -rw-r--r--1 willywilly 22479 Jan 24 16:59 arch/mips64/k
On Sun, May 20, 2001 at 03:11:53PM -0400, Alexander Viro wrote:
> Pheeew... Could you spell "about megabyte of stuff in ioctl.c"?
No.
$ ls -l arch/*/kernel/ioctl32*.c
-rw-r--r--1 willywilly 22479 Jan 24 16:59 arch/mips64/kernel/ioctl32.c
-rw-r--r--1 willywilly 109475 M
On Sun, 20 May 2001, Linus Torvalds wrote:
> Now, a good way to force the issue may be to just remove the "ioctl"
> function pointer from the file operations structure altogether. We don't
> have to force peopel to use "read/write" - we can just make it clear that
> ioctl's _have_ to be wrapped
On Sun, 20 May 2001, Russell King wrote:
>
> On Sun, May 20, 2001 at 11:46:33AM -0700, Linus Torvalds wrote:
> > Nobody will expect the above to work, and everybody will agree that the
> > above is a BUG if the read() call will actually follow the pointer.
>
> I didn't say anything about read().
On Sun, 20 May 2001, David Woodhouse wrote:
>
> If that had been done right the first time, you wouldn't have had to either.
> For that matter, it's often the case that if the ioctl had been done right
> the first time, nobody would have had to fix it up for any architecture.
The problem with i
On Sun, May 20, 2001 at 11:46:33AM -0700, Linus Torvalds wrote:
> Nobody will expect the above to work, and everybody will agree that the
> above is a BUG if the read() call will actually follow the pointer.
I didn't say anything about read(). I said write(). Obviously it
wouldn't work for read
On Sun, 20 May 2001, Russell King wrote:
>
> On Sat, May 19, 2001 at 08:26:20PM -0700, Linus Torvalds wrote:
> > You're missing the point.
>
> I don't think Richard is actually. I think Richard has hit a nail
> dead on its head.
>
> > It's ok to do "read()/write()" on structures.
>
> Ok, we c
Obviously there has to be some standard base
with which to work, especially for computer language
keywords as these can't be converted due to name
clashes. What would be cool is to pick a better base
language than English that everyone would have to
learn to "use computers". This is especially imp
[EMAIL PROTECTED] said:
> I can tell you haven't had to write any 32-bit ioctl emulation code
> for a 64-bit kernel recently.
If that had been done right the first time, you wouldn't have had to either.
For that matter, it's often the case that if the ioctl had been done right
the first time, n
On Sun, 20 May 2001, Russell King wrote:
> I still see read()/write() being a "pass any crap" interface. The
> implementer of the target for read()/write() will probably still be
> a driver which will need to decode what its given, whether its in
> ASCII or binary.
>
> And driver writers are
On Sat, May 19, 2001 at 08:26:20PM -0700, Linus Torvalds wrote:
> You're missing the point.
I don't think Richard is actually. I think Richard has hit a nail
dead on its head.
> It's ok to do "read()/write()" on structures.
Ok, we can read()/write() structures. So someone invents the followin
On Sat, 19 May 2001, Richard Gooch wrote:
>
> Matthew Wilcox writes:
> > On Sat, May 19, 2001 at 10:22:55PM -0400, Richard Gooch wrote:
> > > The transaction(2) syscall can be just as easily abused as ioctl(2) in
> > > this respect.
> >
> > But read() and write() cannot.
>
> Sure they can. I ca
Alexander Viro writes:
>
>
> On Sat, 19 May 2001, Richard Gooch wrote:
>
> > The transaction(2) syscall can be just as easily abused as ioctl(2) in
> > this respect. People can pass pointers to ill-designed structures very
>
> Right. Moreover, it's not needed. The same functionality can be
> t
On Sat, 19 May 2001, Richard Gooch wrote:
> The transaction(2) syscall can be just as easily abused as ioctl(2) in
> this respect. People can pass pointers to ill-designed structures very
Right. Moreover, it's not needed. The same functionality can be trivially
implemented by write() and read(
On Sat, May 19, 2001 at 10:22:55PM -0400, Richard Gooch wrote:
> The transaction(2) syscall can be just as easily abused as ioctl(2) in
> this respect.
But read() and write() cannot.
--
Revolutions do not require corporate support.
-
To unsubscribe from this list: send the line "unsubscribe lin
On Sat, 19 May 2001, Richard Gooch wrote:
> There is another reason to use ioctl(2): when you need to send data to
> the kernel/driver and wait for a response. It supports transactions,
> which read(2) and write(2) cannot. Therefore it remains useful.
Somebody, run to database vendors and tell
Matthew Wilcox writes:
> On Sat, May 19, 2001 at 12:51:23PM -0600, Richard Gooch wrote:
> > Al, if you really want to kill ioctl(2), then perhaps you should
> > implement a transaction(2) syscall. Something like:
> > int transaction (int fd, void *rbuf, size_t rlen,
> > void *
Andries Brouwer writes:
> 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 t
Alan Cox writes:
> > ioctls are evil, period. At least with these names you can use normal
> > scripting and don't need any special tools. Every ioctl means a binary
> > that has no business to exist.
>
> That is not IMHO a rational argument. It isn't my fault that your
> shell does not support i
> On Sun, 20 May 2001, Ingo Oeser wrote:
> > PS: English is neither mine, nor Linus native language. Why do
> >the English natives complain instead of us? ;-)
>
> Because we had some experience with, erm, localized systems and for
> Alan it's most likely pure theory? ;-)
I think its importan
On Sun, 20 May 2001, Ingo Oeser wrote:
> PS: English is neither mine, nor Linus native language. Why do
>the English natives complain instead of us? ;-)
Because we had some experience with, erm, localized systems and for
Alan it's most likely pure theory? ;-)
On Sat, May 19, 2001 at 11:34:48AM -0700, Linus Torvalds wrote:
[Reasons]
> So the "English is bad" argument is a complete non-argument.
Jepp, I have to agree.
English is used more or less as an communication protocol in
computer science and for operating computers.
Once you know how to operat
On Sat, May 19, 2001 at 09:38:03PM +0200, Erik Mouw wrote:
> > But /dev/sda/offset=234234,limit=626737537 isn't a file! ls it and see
> > if it's there. writing to files that aren't shown in directory listings
> > is plain evil. I really don't want to explain why. It's extremely
> > messy and unin
On Sat, May 19, 2001 at 10:45:11AM -0700, Aaron Lehmann wrote:
> On Sat, May 19, 2001 at 06:48:19PM +0200, Erik Mouw wrote:
> > One of the fundamentals of Unix is that "everything is a file" and that
> > you can do everything by reading or writing that file.
>
> But /dev/sda/offset=234234,limit=6
Aaron Lehmann wrote:
> On Sat, May 19, 2001 at 08:05:02PM +0200, [EMAIL PROTECTED] wrote:
> > > 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 RRPA
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.
W
On Sat, 19 May 2001, Alan Cox wrote:
>
> > Now that I'm awake and refreshed, yeah, that's awful. But
> > echo "hot-add,slot=5,device=/dev/sda" >/dev/md0/control *is* sane. Heck,
> > the system can even send back result codes that way.
>
> Only to an English speaker. I suspect Quebec City canad
On Sat, May 19, 2001 at 08:05:02PM +0200, [EMAIL PROTECTED] wrote:
> > 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 not
> 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
On Sat, May 19, 2001 at 01:30:14PM +0200, [EMAIL PROTECTED] wrote:
> I don't think so. It is necessary, and it is good.
>
> But it is easy to make the transition painless.
> Instead of the current choice between INITRD (yes/no)
> we have INITRD (default built-in / external).
> The built-in versio
On Sat, May 19, 2001 at 06:48:19PM +0200, Erik Mouw wrote:
> One of the fundamentals of Unix is that "everything is a file" and that
> you can do everything by reading or writing that file.
But /dev/sda/offset=234234,limit=626737537 isn't a file! ls it and see
if it's there. writing to files that
On Sat, May 19, 2001 at 03:02:47PM +0100, Alan Cox wrote:
> > ioctls are evil, period. At least with these names you can use normal
> > scripting and don't need any special tools. Every ioctl means a binary
> > that has no business to exist.
>
> That is not IMHO a rational argument. It isn't my f
On Sat, May 19, 2001 at 05:25:22PM +0100, Alan Cox wrote:
> Only to an English speaker. I suspect Quebec City canadians would prefer a
> different command set.
Should we support `pas387' as well as `no387' as a kernel boot parameter
then? Face it, a sysadmin has to know the limited subset of eng
On Sat, 19 May 2001, Alan Cox wrote:
> > Now that I'm awake and refreshed, yeah, that's awful. But
> > echo "hot-add,slot=5,device=/dev/sda" >/dev/md0/control *is* sane. Heck,
> > the system can even send back result codes that way.
>
> Only to an English speaker. I suspect Quebec City canad
> Now that I'm awake and refreshed, yeah, that's awful. But
> echo "hot-add,slot=5,device=/dev/sda" >/dev/md0/control *is* sane. Heck,
> the system can even send back result codes that way.
Only to an English speaker. I suspect Quebec City canadians would prefer a
different command set.
-
To un
> ioctls are evil, period. At least with these names you can use normal
> scripting and don't need any special tools. Every ioctl means a binary
> that has no business to exist.
That is not IMHO a rational argument. It isn't my fault that your shell does
not support ioctls usefully. If you used p
[EMAIL PROTECTED] wrote:
>
> Hmm. You know that I wrote this long ago?
Well, let's not get too hung up on the disk thing (yeah,
I started it...).
Ben's intent here is to *demonstrate* how argv-style
info can be passed into device nodes. It seems neat,
and nice.
We can also make use of a stron
Ben LaHaise <[EMAIL PROTECTED]> writes:
> Hey folks,
>
> The work-in-progress patch for-demonstration-purposes-only below consists
> of 3 major components, and is meant to start discussion about the future
> direction of device naming and its interaction block layer. The main
> motivations here
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 sy
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
In article <[EMAIL PROTECTED]> I wrote:
>The only problem I can see with this is that it removes one useful thing,
>the ability to give a user access to a whole partition.
>
>chown wingel /dev/hda5
>
>won't work anymore since there is no such device node.
Apologies, this should have gone to
In article <[EMAIL PROTECTED]> you
write:
>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
> mo
Alexander Viro wrote:
>
> > (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 are the same.
On Sat, 19 May 2001, Andrew Morton wrote:
> Alexander Viro wrote:
> >
> > > (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 *neve
On Sat, 19 May 2001, Ben LaHaise wrote:
> On Sat, 19 May 2001, Alexander Viro wrote:
>
> > On Sat, 19 May 2001, Ben LaHaise wrote:
> >
> > > It's not done yet, but similar techniques would be applied. I envision
> > > that a raid device would support operations such as
> > > open("/dev/md0/sl
On Sat, 19 May 2001, Andrew Clausen wrote:
> Alexander Viro wrote:
> > On Sat, 19 May 2001, Andrew Clausen wrote:
> >
> > > (1) these issues are independent. The partition parsing could
> > > be done in user space, today, by blkpg, if I read the code correctly
> > > ;-) (there's an ioctl for
On Sat, 19 May 2001, Alexander Viro wrote:
> On Sat, 19 May 2001, Ben LaHaise wrote:
>
> > It's not done yet, but similar techniques would be applied. I envision
> > that a raid device would support operations such as
> > open("/dev/md0/slot=5,hot-add=/dev/sda")
>
> Think for a moment and you'll
On Sat, 19 May 2001, Ben LaHaise wrote:
> It's not done yet, but similar techniques would be applied. I envision
> that a raid device would support operations such as
> open("/dev/md0/slot=5,hot-add=/dev/sda")
Think for a moment and you'll see why it's not only ugly as hell, but simply
won't
On Sat, 19 May 2001, Andrew Clausen wrote:
> (1) these issues are independent. The partition parsing could
> be done in user space, today, by blkpg, if I read the code correctly
> ;-) (there's an ioctl for [un]registering partitions) Never
> tried it though ;-)
I tried to imply that through t
On Sat, 19 May 2001, Andrew Clausen wrote:
> (1) these issues are independent. The partition parsing could
> be done in user space, today, by blkpg, if I read the code correctly
> ;-) (there's an ioctl for [un]registering partitions) Never
> tried it though ;-)
ioctls are even more evil tha
Hey folks,
The work-in-progress patch for-demonstration-purposes-only below consists
of 3 major components, and is meant to start discussion about the future
direction of device naming and its interaction block layer. The main
motivations here are the wasting of minor numbers for partitions, and
93 matches
Mail list logo
