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
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, Edgar Toernig wrote:
IMHO any similar powerful (and versatile) interface will see the same
problems. Enforcing a read/write like interface (and rejecting drivers
that pass ptrs through this interface) may give you some knowledge about
the kernel/userspace
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, 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, 19 May 2001 [EMAIL PROTECTED] wrote:
One would like to have a version of the open() call that was
guaranteed free of side effects, and gave a fd only -
perhaps for stat(), perhaps for ioctl().
I did this a while ago, after some discussion. The
implementation may suck, but I think
Why are LVM and EVMS(competing LVM project) needed at all?
I prefer to think of it the other way around
Surely the same can be accomplished with
* md
* snapshot blkdev (attached in previous e-mail)
* giving partitions and blkdevs the ability to grow and shrink
* giving filesystems the
[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 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 Sun, 20 May 2001, Edgar Toernig wrote:
IMHO any scheme that requires a special name to perform ioctl like
functions will not work. Often you don't known the name of the
device you're talking to and then you're lost.
ls -l /proc/self/fd/n
and think of the results. We can export that as
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
How about sprintf(s + strlen(s), foo)?
Solar Designer said two years ago we should be using snprintf in the kernel.
He was most decidedly right 8)
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
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
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
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
[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, 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(). I
18 matches
Mail list logo
