|
From: Nicholas N. <nj...@ca...> - 2004-08-18 13:57:02
|
Hi,
In PRE(mount), we don't do anything for the 5th argument ('data'). Should
we do a pre_mem_read_asciiz? Or does it depend on the file type?
N
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-18 14:15:09
|
On Wed, 18 Aug 2004, Tom Hughes wrote:
>> In PRE(mount), we don't do anything for the 5th argument ('data').
>> Should we do a pre_mem_read_asciiz? Or does it depend on the file
>> type?
>
> The manual page says:
>
> The data argument is interpreted by the different file systems. Typi-
> cally it is a string of comma-separated options understood by this file
> system. See mount(8) for details of the options available for each
> filesystem type.
Yes, I saw that, but I didn't find it (or mount(8)) very illuminating.
N
|
|
From: Paul M. <pa...@sa...> - 2004-08-19 01:35:06
|
Nicholas Nethercote writes: > Yes, I saw that, but I didn't find it (or mount(8)) very illuminating. It's a blob of data, usually a string, and only the filesystem knows how to interpret it or how long it is. :( Paul. |
|
From: Jeremy F. <je...@go...> - 2004-08-18 17:19:17
|
On Wed, 2004-08-18 at 14:56 +0100, Nicholas Nethercote wrote:
> Hi,
>
> In PRE(mount), we don't do anything for the 5th argument ('data'). Should
> we do a pre_mem_read_asciiz? Or does it depend on the file type?
Yeah, it's totally filesystem dependent. Some (most) filesystems treat
it as a string, but some (smb, I think) pass a binary structure.
So the best we can do is ignore it - I don't think we can even
reasonably check that its a properly formed pointer, or completely
defined, since we don't know if its a) being used, or b) being cast to
an int type.
J
|