>> 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
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
> `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
> >
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
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
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
> 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
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 is a
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
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 each
`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, 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 cmd,arg into a structure like type,cmd,inbuf,inlen,outbuf,outlen.
At least make sure that the 'kioctl' returns the number of bytes placed
into 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,
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 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 or which
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.
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/mypartition/size
Alexander Viro writes:
> drivers/net/ppp_generic.c:
> ppp_set_compress(struct ppp *ppp, unsigned long arg)
> {
[snip]
> if (copy_from_user(, (void *) arg, sizeof(data))
> || (data.length <= CCP_MAX_OPTION_LENGTH
> && copy_from_user(ccp_option, data.ptr,
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
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,
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
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,
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
> 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
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
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
[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
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
>
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
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
>
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
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/sda
#
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, might
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,
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, it
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 'reset'
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 not
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
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 fact,
had
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
ioctl's
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 unsubscribe
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 requires
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
[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_
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 command set.
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 did you see
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 read is
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
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
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
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
>> 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
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
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
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"
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
> >
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
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
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
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
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
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
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
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
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
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
[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,
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
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 already
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
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 simply doesn't
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 timescales
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
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 misunderstood. My
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 people
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--r--1 willy
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 also
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
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 following
[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,
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
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 May
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 development in
[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 ioctl's
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 of
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
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, and
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 development in
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 not a
1 - 100 of 181 matches
Mail list logo
