Thanks for testing it but I suspect it has a problem. I have not verified
whether this is possible but imagine two requests for the same kdev_t dev
occur on two CPUs, then unless we protect access to rd_memory[minor] we
will get very bad things to happen.
I thought io_request_lock was supposed to guard this but I need to check
it when I get a spare minute.
Btw, I assume you got the latest version of it, i.e. the one on my site
AFTER I posted "now it is safe to try it"? The very original version had a
bug. If in doubt, get it again from:
http://www.ocston.org/~tigran/patches/ramdisk-2.3.35-pre2.patch
Thanks again for taking time to look at it,
------
Tigran A. Aivazian | http://www.sco.com
Escalations Research Group | tel: +44-(0)1923-813796
Santa Cruz Operation Ltd | http://www.ocston.org/~tigran
On 23 Dec 1999, Jeff Uphoff wrote:
> The following message is a courtesy copy of an article
> that has been posted to linux.dev.kernel as well.
>
> "TA" == Tigran Aivazian <tigran@sco.COM> writes:
>
> TA> Please review it:
> TA> http://www.ocston.org/~tigran/patches/ramdisk-2.3.35-pre2.patch
> TA> Tested only plain ramdisk part (not initrd, i.e.)
>
> Testing on initrd & it *almost* works: it mounts and some files are OK
> (e.g. my /bin/sh executes), but at least one (/linuxrc in this
> case...uh-oh!) shows up with its correct length but any reads on the
> file return as many NULLs as there are characters in the file.
>
> Investigating....
>
> --Up.
>
> --
> Jeffrey A. Uphoff
> Member of Technical Staff
> Transmeta Corporation
> Santa Clara, California, USA
>
-
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.tux.org/lkml/