Confused about mount

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

Ok, it’s time to fix the ramdisk so that it supports mounts.

I understand that I have to use resmgr_attach with an _FTYPE_MOUNT,
and _RESMGR_FLAG_DIR | _RESMGR_FLAG_FTYPEONLY and with no name
if I want to at least see the mount requests.

That all works – I see the mount requests coming in to my io_mount()
handler…

What I’m confused about now is the relationship between the unnamed
resource just created, and the “block special device” that I feel
a need to create.

If I understand things correctly, I’ll need to create:
a) the unnamed device (as above)
b) the named special device (let’s say /dev/ramdisk)

Then, when a mount request comes in:

mount -T ramdisk /dev/ramdisk /home/user1

I will create another mountpoint at /home/user1.

I’m confused about the special device.
What should its attributes be? (block special?)
Does it need to have a mount() handler as well?

The confusion stems from the fact that it seems a little bit
redundant to have an unnamed device that’s then used to take
a special device name that then gets mounted – to my way
of thinking, I really want to create just the special device
/dev/ramdisk and have the user mount that where-ever they like.
But does that work with multiple mounts? I want to be able to:

mount -T ramdisk -omax=2M /dev/ramdisk /home/user1
mount -T ramdisk -omax=200M /dev/ramdisk /home/user2

to have several mountpoints for different ramdisks, each with
different options (in this case, for example, the max size).

Any suggestions?

Thanks in advance!

Cheers,
-RK

Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

2

Robert Krten <nospam83@parse.com> wrote:

What I’m confused about now is the relationship between the unnamed
resource just created, and the “block special device” that I feel
a need to create.

There is not need to do this. This is basically the difference
between “mount -t” and “mount -T”; with ‘-t’ you are mounting on
top of some resource explicitly managed by that server (like a
“/dev/hd0t77” partition for a disk filesystem); with ‘-T’ there
is not necessarily such a thing (eg io-net style mounting). The
way you claim this type (_IO_CONNECT_EXTRA_MOUNT) from the more
traditional filesystem one (_IO_CONNECT_EXTRA_MOUNT_OCB) is by
matching the ‘extra->extra.srv.type’ (“ramdisk” in your example).

Then, when a mount request comes in:
mount -T ramdisk /dev/ramdisk /home/user1
I’m confused about the special device.

Why bother?! Just “mount -Tramdisk /home/user1”, ignore the
‘extra->extra.srv.special’ (which should be empty anyway), and
mount at ‘msg->connect.path’.

3

Xiaodan Tang <xtang@qnx.com> wrote:

John Garvey <> jgarvey@qnx.com> > wrote in message
news:avu1cg$4vm$> 1@nntp.qnx.com> …
Robert Krten <> nospam83@parse.com> > wrote:
Then, when a mount request comes in:
mount -T ramdisk /dev/ramdisk /home/user1
I’m confused about the special device.

Why bother?! Just “mount -Tramdisk /home/user1”, ignore the
‘extra->extra.srv.special’ (which should be empty anyway), and
mount at ‘msg->connect.path’.

This reminds me > :slight_smile:

How can I figure out how many “mount handled resmgr” on a running system ?
These special types “io-net”, “io-audio”, “ramdisk” seems silent unless you
know they are exist.

Maybe a pidin short hand is necessary ? Collin ?

Pushing my luck here – how about “what’s the magic necessary to make
“df” show my mountpoint” ? I notice it stat()s my resmgr, but what
is it looking for to trigger it to list me? Thanks! :slight_smile:

Cheers,
-RK

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

4

John Garvey <jgarvey@qnx.com> wrote in message
news:avu1cg$4vm$1@nntp.qnx.com…

Robert Krten <> nospam83@parse.com> > wrote:
Then, when a mount request comes in:
mount -T ramdisk /dev/ramdisk /home/user1
I’m confused about the special device.

Why bother?! Just “mount -Tramdisk /home/user1”, ignore the
‘extra->extra.srv.special’ (which should be empty anyway), and
mount at ‘msg->connect.path’.

This reminds me :slight_smile:

How can I figure out how many “mount handled resmgr” on a running system ?
These special types “io-net”, “io-audio”, “ramdisk” seems silent unless you
know they are exist.

Maybe a pidin short hand is necessary ? Collin ?

-xtang

5

Xiaodan Tang <xtang@qnx.com> wrote:

John Garvey <> jgarvey@qnx.com> > wrote in message
Why bother?! Just “mount -Tramdisk /home/user1”, ignore the
‘extra->extra.srv.special’ (which should be empty anyway), and
mount at ‘msg->connect.path’.
This reminds me > :slight_smile:
How can I figure out how many “mount handled resmgr” on a running system ?
These special types “io-net”, “io-audio”, “ramdisk” seems silent unless you
know they are exist.

Something like: find /proc/mount -name “,,,,11” and then match
the pid to a name? Could probably do this with an awk script :wink:
But as to what type they respond to, since that is just a runtime
strcmp(), I don’t think it is available … I’ve always put the type
into the f_basetype field of a statvfs() (although you’re obviously
already mounted by then :slight_smile:

6

John Garvey <jgarvey@qnx.com> wrote:

Robert Krten <> nospam83@parse.com> > wrote:
John Garvey <> jgarvey@qnx.com> > wrote in message
news:avu1cg$4vm$> 1@nntp.qnx.com> …
Robert Krten <> nospam83@parse.com> > wrote:
Pushing my luck here – how about “what’s the magic necessary to make
“df” show my mountpoint” ? I notice it stat()s my resmgr, but what
is it looking for to trigger it to list me? Thanks! > :slight_smile:

‘df’ in its default walk will pick up all mounted filesystems from
/proc/mount (with _FTYPE_ANY and mode dir/reg/blk). Try giving it
a path to your ramdisk (“df /ramdisk”) and see if the problem is
actually with discovery or processing. You should support the
following devctls() for complete integration - DCMD_FSYS_STATVFS,
DCMD_FSYS_MOUNTED_ON, DCMD_FSYS_MOUNTED_AT, DCMD_FSYS_MOUNTED_BY.

Thanks John,
the problem is with discovery; “df /ramdisk” works fine… I’ll
take a closer look tonight at the code.

Cheers,
-RK

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

7

Robert Krten <nospam83@parse.com> wrote:

John Garvey <> jgarvey@qnx.com> > wrote in message
news:avu1cg$4vm$> 1@nntp.qnx.com> …
Robert Krten <> nospam83@parse.com> > wrote:
Pushing my luck here – how about “what’s the magic necessary to make
“df” show my mountpoint” ? I notice it stat()s my resmgr, but what
is it looking for to trigger it to list me? Thanks! > :slight_smile:

‘df’ in its default walk will pick up all mounted filesystems from
/proc/mount (with _FTYPE_ANY and mode dir/reg/blk). Try giving it
a path to your ramdisk (“df /ramdisk”) and see if the problem is
actually with discovery or processing. You should support the
following devctls() for complete integration - DCMD_FSYS_STATVFS,
DCMD_FSYS_MOUNTED_ON, DCMD_FSYS_MOUNTED_AT, DCMD_FSYS_MOUNTED_BY.

8

John Garvey <jgarvey@qnx.com> wrote:

Robert Krten <> nospam83@parse.com> > wrote:
What I’m confused about now is the relationship between the unnamed
resource just created, and the “block special device” that I feel
a need to create.

There is not need to do this. This is basically the difference
between “mount -t” and “mount -T”; with ‘-t’ you are mounting on
top of some resource explicitly managed by that server (like a
“/dev/hd0t77” partition for a disk filesystem); with ‘-T’ there
is not necessarily such a thing (eg io-net style mounting). The
way you claim this type (_IO_CONNECT_EXTRA_MOUNT) from the more
traditional filesystem one (_IO_CONNECT_EXTRA_MOUNT_OCB) is by
matching the ‘extra->extra.srv.type’ (“ramdisk” in your example).

Then, when a mount request comes in:
mount -T ramdisk /dev/ramdisk /home/user1
I’m confused about the special device.

Why bother?! Just “mount -Tramdisk /home/user1”, ignore the
‘extra->extra.srv.special’ (which should be empty anyway), and
mount at ‘msg->connect.path’.

Hmmm… except the exact opposite happens!

If I do “mount -T ramdisk /ramdisk”, then it turns out the
the special string has “/ramdisk” in it, and the mount string
at msg → connect.path is empty.

The extra.srv.type does in fact come in as “ramdisk”, so
that part’s ok…

I have no great emotional problems with using the special string
instead of the connect.path, but would like to clarify that
that in fact is what I should be doing… I’m always a little
leary when something works the opposite to the way it’s described :slight_smile:

(Same thing if I do “mount -t ramdisk /ramdisk”, btw; they both
(-t and -T) come in as extra type 0xa, which is EXTRA_MOUNT and
not the OCB version; just as we’d expect).

Cheers,
-RK

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

9

Robert Krten <nospam83@parse.com> wrote:

John Garvey <> jgarvey@qnx.com> > wrote:
Robert Krten <> nospam83@parse.com> > wrote:
John Garvey <> jgarvey@qnx.com> > wrote in message
news:avu1cg$4vm$> 1@nntp.qnx.com> …
Robert Krten <> nospam83@parse.com> > wrote:
Pushing my luck here – how about “what’s the magic necessary to make
“df” show my mountpoint” ? I notice it stat()s my resmgr, but what
is it looking for to trigger it to list me? Thanks! > :slight_smile:

‘df’ in its default walk will pick up all mounted filesystems from
/proc/mount (with _FTYPE_ANY and mode dir/reg/blk). Try giving it
a path to your ramdisk (“df /ramdisk”) and see if the problem is
actually with discovery or processing. You should support the
following devctls() for complete integration - DCMD_FSYS_STATVFS,
DCMD_FSYS_MOUNTED_ON, DCMD_FSYS_MOUNTED_AT, DCMD_FSYS_MOUNTED_BY.

Thanks John,
the problem is with discovery; “df /ramdisk” works fine… I’ll
take a closer look tonight at the code.

Once again, “pretend” I’m stupid :slight_smile:

I created the initial mountpoint:
resmgr_attach (dpp, &resmgr_attr, NULL, _FTYPE_MOUNT, _RESMGR_FLAG_DIR | _RESMGR_FLAG_FTYPEONLY, &mount_only_cfuncs, NULL, NULL);

I then mount this:
mount -t ramdisk /ramdisk

This ends up calling:
resmgr_attach (dpp, &resmgr_attr, “/ramdisk”, _FTYPE_ANY, _RESMGR_FLAG_DIR, &connect_func, &io_func, &cfs_attr → attr);

My ramdisk is now present (let’s say it’s process ID 610259027).

ls -l /proc/mount shows (amongst others):
dr-xr-xr-x 2 root root 1 Jan 13 18:22 0,610259027,1,0,11/

df /ramdisk shows:
/ramdisk 8 0 8 0% /ramdisk

df (without the pathname) doesn’t show my device.

Sorry to keep bugging you about this – just trying to get it right :slight_smile:

Cheers,
-RK

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

10

Robert Krten <nospam83@parse.com> wrote:

Then, when a mount request comes in:
mount -T ramdisk /dev/ramdisk /home/user1
I’m confused about the special device.
Why bother?! Just “mount -Tramdisk /home/user1”, ignore the
‘extra->extra.srv.special’ (which should be empty anyway), and
mount at ‘msg->connect.path’.
Hmmm… except the exact opposite happens!

Oops, looking at the wrong code, yes it is the other way around.
“mount -Tt a” will have a in the special string and path empty;
“mount -Tt a b” will have a in the special and b in the path.
The first situation is the normal for ‘-T’. Anyway, you’d
always want the ‘extra->extra.srv.special’ path as you saw.

(Same thing if I do “mount -t ramdisk /ramdisk”, btw; they both
(-t and -T) come in as extra type 0xa, which is EXTRA_MOUNT and
not the OCB version; just as we’d expect).

There is quite a lot of, um, magic in mount and mount(); in the
case where there is no special to mount on top of you definitely
want to use ‘-T’. Here’s some comments from mount, thomasf can
explain more details if necessary …

-t type implies that the special device and path will both exist,
and if the special device exists it should be opened and
an OCB for that device should be send to the path.

-T type implies that the special device doesn’t necessarily have
to exist, and NO OCB will be send along with the path
if the device doesn’t exist.

11

Robert Krten <nospam83@parse.com> wrote:

I created the initial mountpoint:
resmgr_attach (dpp, &resmgr_attr, NULL, _FTYPE_MOUNT, _RESMGR_FLAG_DIR | _RESMGR_FLAG_FTYPEONLY, &mount_only_cfuncs, NULL, NULL);

That is the “mount catcher”, looks OK (and must be if you get _IO_MOUNT).

This ends up calling:
resmgr_attach (dpp, &resmgr_attr, “/ramdisk”, _FTYPE_ANY, _RESMGR_FLAG_DIR, &connect_func, &io_func, &cfs_attr → attr);

That is the filesystem, looks OK.

ls -l /proc/mount shows (amongst others):
dr-xr-xr-x 2 root root 1 Jan 13 18:22 0,610259027,1,0,11/

That’s just the mount catcher (type 11 = FTYPE_MOUNT); there should also
be a “0,610259027,1,?,0” under “/proc/mount/ramdisk” - is there? And
“ls -ld /proc/mount/ramdisk/0,610259027,1,?,0” should be the root
directory of your ramdisk filesystem - is it? Compare with what
devb-eide entries are in there.

df (without the pathname) doesn’t show my device.

If the above entries exist in the pathname space (which they should
as they appear there magically in response to resmgr_attach()), then
df should iterate into you. You say you get a fstat)( call? That
is the first step, provided you are REG/DIR/BLK you will then start
to get the DCMD_FSYS_MOUNTED_* devctl()s as df tries to work out
just what you are and culminating in a statvfs() request. Do you
properly handle the stat dev/rdev fields (df uses these to not report
on duplicates, like both “/” and “/dev/hd0t79” - probably not an
issue for you as you only have a single pathname representation)?
What about the dev/ino fields?

Since you get invoked for “df /ramdisk”, then it must be the
discovery phase, but that it only an fstat(), or you fail the
dev/ino uniqueness test (as an easy out for managers which don’t
do it properly df will skip this test if either dev or ino are 0,
so this shouldn’t be getting you either, but check what you’re
reporting in the stat dev/rdev/ino fields of your ramdisk root).