lkml.org 
[lkml]   [1998]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] New phys_addr() syscall
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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.060 / U:23.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site