Re: [PATCH] New phys_addr() syscall

Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Mon, 20 Jul 1998 10:02:51 +1000


Alan Cox writes:
> > OK, so it's not a safe and clean mechanism. On the other hand, if you
> > want a fast and dirty mechanism, it should work fine. Something akin
> > to the U-NET ATM drivers could use it.
>
> The right way to do this currently is a driver that kmalloc/vmallocs
> buffers and maps them to user space combined with a phys<->virt ioctl
> and also irq support in the same way - this will materially help XFree
> support for the latest cards

What's the likely latency between IRQ sent and process starts running?
Last time I looked even a realtime process which is sleeping won't be
scheduled immediately if a lower priority process is banging the CPU.

> > Note: I'm not saying that this is the way networking should be done!
> > It's just something that I noticed you could do if you wanted.
>
> I still don't think it should be a syscall - an ioctl on /dev/mem maybe

But that then requires privileges: /dev/mem isn't something you'd let
every process peek at. I don't see why a simple memory tester needs to
be suid-root (or sgid-root).

Is your concern about a syscall that the number of syscalls is
limited? In that case the syscall could be renamed to something more
generic and take a command argument. Alternatively a new device file
could be created which everyone could access.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html