Re: More better in mount(2)

Linda Walsh writes: > Andreas Dilger wrote: > > Why not simply use the existing mount options mechanism, and have the > > filesystem parse the options. You would need to have the options as > > strings. > > Would that be advisable for file-system independant options? I'm wanting > something that

Re: More better in mount(2)

hi, On Jan 4, 6:45pm, LA Walsh wrote: > Subject: RE: More better in mount(2) > > > > Each filesystem can parse its own options > --- > Yes, and? How does that help the kernel apply file-system > independent and/or systemwide options? Think of it as the same > as the 'read-only'/'read-w

RE: More better in mount(2)

> -Original Message- > From: Nathan Scott [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 05, 2001 7:42 AM > To: LA Walsh > Cc: [EMAIL PROTECTED] > Subject: Re: More better in mount(2) > > > hi Linda, > > Each filesystem can parse its own options --- Yes, and? How does t

Re: More better in mount(2)

On Jan 5, 3:26am, Daniel Phillips wrote: > Subject: Re: More better in mount(2) > ... > This filesystem mount option parsing code is completely ad hoc, and uses > strtok which is horribly horribly broken. (Do man strtok and read the > 'Bugs' section.) > > It would be worth thinking about how to

Re: More better in mount(2)

On Fri, 05 Jan 2001, Nathan Scott wrote: > hi Linda, > > On Jan 4, 4:11pm, LA Walsh wrote: > > Subject: RE: More better in mount(2) > > > > > Ugly. We already have an options parameter. > > > Just mount with -o security="all_my_security_stuff" > > > and let the kernel parse it. > > > > > > Andr

Re: More better in mount(2)

hi Linda, On Jan 4, 4:11pm, LA Walsh wrote: > Subject: RE: More better in mount(2) > > > Ugly. We already have an options parameter. > > Just mount with -o security="all_my_security_stuff" > > and let the kernel parse it. > > > > Andries > > A parser in the kernel? Neat idea, but I was ho

RE: More better in mount(2)

> -Original Message- > From: [EMAIL PROTECTED] > > > I'd like to be able to pass through a fs-independent 'data' > field to mount. > > I'm thinking if a mount flag is passed in (say MS_EXTRA = 16384 > in fs.h), > > then a 6th parameter is expected. > > Ugly. We already have an options par

Re: More better in mount(2)

> I'd like to be able to pass through a fs-independent 'data' field to mount. > I'm thinking if a mount flag is passed in (say MS_EXTRA = 16384 in fs.h), > then a 6th parameter is expected. Ugly. We already have an options parameter. Just mount with -o security="all_my_security_stuff" and let th

RE: More better in mount(2)

> Linda Walsh writes: > > I'd like to be able to pass through a fs-independent 'data' field to mount. > > Why not simply use the existing mount options mechanism, and have the > filesystem parse the options. You would need to have the options as > strings. --- Would that be advisable for

Re: More better in mount(2)

Linda Walsh writes: > I'd like to be able to pass through a fs-independent 'data' field to mount. > > I'm thinking if a mount flag is passed in (say MS_EXTRA = 16384 in fs.h), > then > a 6th parameter is expected. That 6th parameter would be a list of the > form: Why not simply use the existing

More better in mount(2)

I'd like to be able to pass through a fs-independent 'data' field to mount. I'm thinking if a mount flag is passed in (say MS_EXTRA = 16384 in fs.h), then a 6th parameter is expected. That 6th parameter would be a list of the form: |16-bit signed data length|16-bit signed record type|data|. A r