rsrcdbmgr_devno_attach problem on abnormal exit from DDD

[David_Alessio]

Hmmm, can’t cross post. I’ll drop OS.



Hello,


I’m posting this to both OS and DEVTOOLS since it refers to a bugs that
potentially involve both DDD and the OS cleaning up rsrcdb.

In resmgrs that must not be instantiated more than once, I use the
following code segment:

#define RESMGR_NAME “NULL”
#define DEV_NAME “/DEV/” RESMGR_NAME // don’t edit

// ensure that the driver is not already running
// request a minor number of 0
// if we get it, we’re the first instantiation.

void
im_alone(void)
{
int myminor = 0;
int major_minor;

major_minor = rsrcdbmgr_devno_attach(RESMGR_NAME, myminor, 0);
if (-1 == major_minor)
{
fprintf(stderr, “\nError: Is ‘%s’ already started?\n”, DEV_NAME);
perror(“devno_attach Failed”);
exit(-1);
}
}

\ \ \ While debugging my resmgr with DDD, I ended the session by clicking on DDD's title bar's Exit button (top right). DDD received a SIGSEGV. This is one problem; a fairly repeatable one. The second problem is that the OS didn't detach my resmgr's entry in the rsrcdb.

Who should clean up the rsrcdb? The OS or DDD?
How can I view the rsrcdb?
Could I have fixed rsrcdb manually (I had to reboot – ouch)?

I don’t see this problem when my resmgr receives a signal it can’t
handle. Is the solution as simple as having DDD’s handler pass SIGSEGV
down to the application (before it solicits a bug report)?


Thanks,
-david

[Colin_Burgess1]

Firstly, I would suggest the name_attach() commands rather than
the resource database as a way of preventing multiple servers.

Secondly, when DDD dies (which sounds like an Xphoton bug),
does it clean up your gdb/pdebug/executable?

David Alessio <david.alessio@hsa.hitachi.com> wrote:

Hmmm, can’t cross post. I’ll drop OS.



Hello,



I’m posting this to both OS and DEVTOOLS since it refers to a bugs that
potentially involve both DDD and the OS cleaning up rsrcdb.

In resmgrs that must not be instantiated more than once, I use the
following code segment:



SNIP

#define RESMGR_NAME “NULL”
#define DEV_NAME “/DEV/” RESMGR_NAME // don’t edit

// ensure that the driver is not already running
// request a minor number of 0
// if we get it, we’re the first instantiation.

void
im_alone(void)
{
int myminor = 0;
int major_minor;

major_minor = rsrcdbmgr_devno_attach(RESMGR_NAME, myminor, 0);
if (-1 == major_minor)
{
fprintf(stderr, “\nError: Is ‘%s’ already started?\n”, DEV_NAME);
perror(“devno_attach Failed”);
exit(-1);
}
}

/SNIP



While debugging my resmgr with DDD, I ended the session by clicking on
DDD’s title bar’s Exit button (top right). DDD received a SIGSEGV.
This is one problem; a fairly repeatable one. The second problem is
that the OS didn’t detach my resmgr’s entry in the rsrcdb.

Who should clean up the rsrcdb? The OS or DDD?
How can I view the rsrcdb?
Could I have fixed rsrcdb manually (I had to reboot – ouch)?

I don’t see this problem when my resmgr receives a signal it can’t
handle. Is the solution as simple as having DDD’s handler pass SIGSEGV
down to the application (before it solicits a bug report)?



Thanks,
-david

–
cburgess@qnx.com

[David_Alessio]

Colin Burgess wrote:

Firstly, I would suggest the name_attach() commands rather than
the resource database as a way of preventing multiple servers.

Yes, but I lost this argument to PeterV at the Vancouver Conf.
qnx_name_attach() is how it was done in QNX4, but with NTO’s
name_attach(), a dispatch structure and channel are also created;
something a full resmgr acquires through other means.

Secondly, when DDD dies (which sounds like an Xphoton bug),

No doubt. Xphoton is usable and we’re glad to have it but it’s a long
way from shedding it’s beta status…

does it clean up your gdb/pdebug/executable?

I believe so. I don’t see any other problems.

David Alessio <> david.alessio@hsa.hitachi.com> > wrote:

Hmmm, can’t cross post. I’ll drop OS.

Hello,

I’m posting this to both OS and DEVTOOLS since it refers to a bugs that
potentially involve both DDD and the OS cleaning up rsrcdb.

In resmgrs that must not be instantiated more than once, I use the
following code segment:

SNIP

#define RESMGR_NAME “NULL”
#define DEV_NAME “/DEV/” RESMGR_NAME // don’t edit

// ensure that the driver is not already running
// request a minor number of 0
// if we get it, we’re the first instantiation.

void
im_alone(void)
{
int myminor = 0;
int major_minor;

major_minor = rsrcdbmgr_devno_attach(RESMGR_NAME, myminor, 0);
if (-1 == major_minor)
{
fprintf(stderr, “\nError: Is ‘%s’ already started?\n”, DEV_NAME);
perror(“devno_attach Failed”);
exit(-1);
}
}

/SNIP

While debugging my resmgr with DDD, I ended the session by clicking on
DDD’s title bar’s Exit button (top right). DDD received a SIGSEGV.
This is one problem; a fairly repeatable one. The second problem is
that the OS didn’t detach my resmgr’s entry in the rsrcdb.

Who should clean up the rsrcdb? The OS or DDD?
How can I view the rsrcdb?
Could I have fixed rsrcdb manually (I had to reboot – ouch)?

I don’t see this problem when my resmgr receives a signal it can’t
handle. Is the solution as simple as having DDD’s handler pass SIGSEGV
down to the application (before it solicits a bug report)?

Thanks,
-david

–
cburgess@qnx.com

[system]

David Alessio <david.alessio@hsa.hitachi.com> wrote:

Colin Burgess wrote:

Firstly, I would suggest the name_attach() commands rather than
the resource database as a way of preventing multiple servers.

Yes, but I lost this argument to PeterV at the Vancouver Conf.
qnx_name_attach() is how it was done in QNX4, but with NTO’s
name_attach(), a dispatch structure and channel are also created;
something a full resmgr acquires through other means.

Using the resource database for the major/minor numbers is fine,
but remember that this is a database with a limit of 64 major
value which can get chewed up pretty quickly in an active system
if everyone was diving in to the resource database.

To answer your question however, yes the resource database
should have de-allocated the resource after your program
fully exited (which means exiting out of DDD most likely).

Thomas

David Alessio <> david.alessio@hsa.hitachi.com> > wrote:

Hmmm, can’t cross post. I’ll drop OS.

Hello,

I’m posting this to both OS and DEVTOOLS since it refers to a bugs that
potentially involve both DDD and the OS cleaning up rsrcdb.

In resmgrs that must not be instantiated more than once, I use the
following code segment:

SNIP

#define RESMGR_NAME “NULL”
#define DEV_NAME “/DEV/” RESMGR_NAME // don’t edit

// ensure that the driver is not already running
// request a minor number of 0
// if we get it, we’re the first instantiation.

void
im_alone(void)
{
int myminor = 0;
int major_minor;

major_minor = rsrcdbmgr_devno_attach(RESMGR_NAME, myminor, 0);
if (-1 == major_minor)
{
fprintf(stderr, “\nError: Is ‘%s’ already started?\n”, DEV_NAME);
perror(“devno_attach Failed”);
exit(-1);
}
}

/SNIP

While debugging my resmgr with DDD, I ended the session by clicking on
DDD’s title bar’s Exit button (top right). DDD received a SIGSEGV.
This is one problem; a fairly repeatable one. The second problem is
that the OS didn’t detach my resmgr’s entry in the rsrcdb.

Who should clean up the rsrcdb? The OS or DDD?
How can I view the rsrcdb?
Could I have fixed rsrcdb manually (I had to reboot – ouch)?

I don’t see this problem when my resmgr receives a signal it can’t
handle. Is the solution as simple as having DDD’s handler pass SIGSEGV
down to the application (before it solicits a bug report)?

Thanks,
-david

–
cburgess@qnx.com

–

Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf

[David_Alessio]

thomasf@qnx.com wrote:

David Alessio <> david.alessio@hsa.hitachi.com> > wrote:

Colin Burgess wrote:

Firstly, I would suggest the name_attach() commands rather than
the resource database as a way of preventing multiple servers.

Yes, but I lost this argument to PeterV at the Vancouver Conf.
qnx_name_attach() is how it was done in QNX4, but with NTO’s
name_attach(), a dispatch structure and channel are also created;
something a full resmgr acquires through other means.

Using the resource database for the major/minor numbers is fine,
but remember that this is a database with a limit of 64 major

I was not aware of this. Clearly this can/will quickly become a problem
– I can easily imagine a scenario of 30+ unique resmgrs running…

value which can get chewed up pretty quickly in an active system
if everyone was diving in to the resource database.

Agreed. So, what is the “right” way for a full resmgr to prevent
accidental multiple-instantiation?

The resource DB has a limit; today it’s 64. Filename mechanisms have
race conditions; so they won’t work. name_attach() has evolved beyond
qnx_name_attach() and is no longer, IMHO, an elegant solution.

The problem here is as philosophical as it is technical. It should not
be the responsibility of the ResDB, FSys, or the application to insure
uniqueness in the /dev/ name space – the responsibility should fall to
the only atomic function that attaches the name. IMHO, the cleanest way
would be for resmgr_attach to accept a new flag _RESMGR_FLAG_UNIQUE:
Flags:
_RESMGR_FLAG_UNIQUE
Force resmgr_attach() to fail if the pathname
already exists.


Should we move this thread to OS since I digress from devtools?

-david

To answer your question however, yes the resource database
should have de-allocated the resource after your program
fully exited (which means exiting out of DDD most likely).

May I assume a PR has been entered against this?

Thomas

[system]

David Alessio <david.alessio@hsa.hitachi.com> wrote:

thomasf@qnx.com > wrote:
David Alessio <> david.alessio@hsa.hitachi.com> > wrote:
Colin Burgess wrote:

Firstly, I would suggest the name_attach() commands rather than
the resource database as a way of preventing multiple servers.

Yes, but I lost this argument to PeterV at the Vancouver Conf.
qnx_name_attach() is how it was done in QNX4, but with NTO’s
name_attach(), a dispatch structure and channel are also created;
something a full resmgr acquires through other means.

Using the resource database for the major/minor numbers is fine,
but remember that this is a database with a limit of 64 major

I was not aware of this. Clearly this can/will quickly become a problem
– I can easily imagine a scenario of 30+ unique resmgrs running…

value which can get chewed up pretty quickly in an active system
if everyone was diving in to the resource database.

Agreed. So, what is the “right” way for a full resmgr to prevent
accidental multiple-instantiation?

The resource DB has a limit; today it’s 64. Filename mechanisms have
race conditions; so they won’t work. name_attach() has evolved beyond
qnx_name_attach() and is no longer, IMHO, an elegant solution.

The problem here is as philosophical as it is technical. It should not
be the responsibility of the ResDB, FSys, or the application to insure
uniqueness in the /dev/ name space – the responsibility should fall to
the only atomic function that attaches the name. IMHO, the cleanest way
would be for resmgr_attach to accept a new flag _RESMGR_FLAG_UNIQUE:
Flags:
_RESMGR_FLAG_UNIQUE
Force resmgr_attach() to fail if the pathname
already exists.

Should we move this thread to OS since I digress from devtools?

If you defined what UNIQUE means that might be fine.

I want to attach a name /dev/1

-If /dev/1 already attached, it is clear I should fail.
-If /dev/1/2 already attached, should I fail?
-If /dev/ already attached, should I fail?

The problem is that the _RESMGR_FLAG_UNIQUE would only make sense
in the case where you don’t specify _RESMGR_FLAG_DIR, and the only
guaranteed way to check without deadlock possiblity would be in
the first case.

I do think that it might be a useful flag to have (as lobbied for
by Mario) and your concerns are noted. The major minor “problem”
is one which we are aware of and not really happy about at all.

Thomas … here to make your life easier, not harder.

Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf

[David_Alessio]

thomasf@qnx.com wrote:

David Alessio <> david.alessio@hsa.hitachi.com> > wrote:
thomasf@qnx.com > wrote:
David Alessio <> david.alessio@hsa.hitachi.com> > wrote:
Colin Burgess wrote:

Firstly, I would suggest the name_attach() commands rather than
the resource database as a way of preventing multiple servers.

Yes, but I lost this argument to PeterV at the Vancouver Conf.
qnx_name_attach() is how it was done in QNX4, but with NTO’s
name_attach(), a dispatch structure and channel are also created;
something a full resmgr acquires through other means.

Using the resource database for the major/minor numbers is fine,
but remember that this is a database with a limit of 64 major

I was not aware of this. Clearly this can/will quickly become a problem
– I can easily imagine a scenario of 30+ unique resmgrs running…

value which can get chewed up pretty quickly in an active system
if everyone was diving in to the resource database.

Agreed. So, what is the “right” way for a full resmgr to prevent
accidental multiple-instantiation?

The resource DB has a limit; today it’s 64. Filename mechanisms have
race conditions; so they won’t work. name_attach() has evolved beyond
qnx_name_attach() and is no longer, IMHO, an elegant solution.

The problem here is as philosophical as it is technical. It should not
be the responsibility of the ResDB, FSys, or the application to insure
uniqueness in the /dev/ name space – the responsibility should fall to
the only atomic function that attaches the name. IMHO, the cleanest way
would be for resmgr_attach to accept a new flag _RESMGR_FLAG_UNIQUE:
Flags:
_RESMGR_FLAG_UNIQUE
Force resmgr_attach() to fail if the pathname
already exists.

Should we move this thread to OS since I digress from devtools?

If you defined what UNIQUE means that might be fine.

I want to attach a name /dev/1

-If /dev/1 already attached, it is clear I should fail.
Yes



-If /dev/1/2 already attached, should I fail?
Follow the same logic detailed in resmgr_attach/_RESMGR_FLAG_DIR – no

dir beneath a file.
If /dev/1/2 is a dir and you want to attach /dev/1 as a file, then yes
it should fail. Otherwise it seems legal to me.

-If /dev/ already attached, should I fail?
Clearly not.



The problem is that the _RESMGR_FLAG_UNIQUE would only make sense
in the case where you don’t specify _RESMGR_FLAG_DIR, and the only

I’m not sure if I should agree with this. Isn’t this just a sub-class
of your first case?

If I attach a name /dev/1 with (_RESMGR_FLAG_DIR | _RESMGR_FLAG_UNIQUE)
it should fail if /dev/1 exists as either a dir or a file.

But if /dev/1/2 already exists as a file, I don’t see a problem.

guaranteed way to check without deadlock possiblity would be in
the first case.

I do think that it might be a useful flag to have (as lobbied for
by Mario) and your concerns are noted. The major minor “problem”
is one which we are aware of and not really happy about at all.

Thomas … here to make your life easier, not harder.

Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com > Neutrino Development Group
(613)-591-0931 > http://www.qnx.com/~thomasf

[system]

David Alessio <david.alessio@hsa.hitachi.com> wrote:

thomasf@qnx.com > wrote:

I want to attach a name /dev/1

-If /dev/1 already attached, it is clear I should fail.
Yes

-If /dev/1/2 already attached, should I fail?

Follow the same logic detailed in resmgr_attach/_RESMGR_FLAG_DIR – no
dir beneath a file.
If /dev/1/2 is a dir and you want to attach /dev/1 as a file, then yes
it should fail. Otherwise it seems legal to me.

Except that is a policy which is suggested to programmers but not
a rule actually enforced. If you want to do something odd like
that (put a file in the same location as a directory), you can,
the system won’t stop you.

-If /dev/ already attached, should I fail?
Clearly not.

Why not … /dev as a “directory” resource manager could be
providing an instance of /dev/1, and it may be a conditional
file so that the path manager has no way of guaranteeing if
that file exists in any atomic fashion.

The problem is that the _RESMGR_FLAG_UNIQUE would only make sense
in the case where you don’t specify _RESMGR_FLAG_DIR, and the only

I’m not sure if I should agree with this. Isn’t this just a sub-class
of your first case?

If I attach a name /dev/1 with (_RESMGR_FLAG_DIR | _RESMGR_FLAG_UNIQUE)
it should fail if /dev/1 exists as either a dir or a file.

But if /dev/1/2 already exists as a file, I don’t see a problem.

The question here is what is the purpose of the UNIQUE
flag. Is it to guarantee that there is no manager who
is already registered at a given mountpoint. This is a
condition which can easily be guaranteed since it is
entirely within the realm of the path manager.

If the purpose is to guarantee that there is nothing else
in the system which is using that “path” before we perform
an attach (ala O_EXCL), then regardless of how much effort
we go to, the path manager can make no such guarantees. If
it can’t be guaranteed then it is of no use to anyone.

I’d be willing to concede to the validity and usefullness of
the first case, but not to the second.

Additional food for thought is to consider what guarantees
one would expect to have about the meaning of the UNIQUE
mountpoint. Would this forbid others (non-unique) from
mounting on this path?

Thomas

Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf

[David_Alessio]

thomasf@qnx.com wrote:

David Alessio <> david.alessio@hsa.hitachi.com> > wrote:
thomasf@qnx.com > wrote:

I want to attach a name /dev/1

-If /dev/1 already attached, it is clear I should fail.
Yes

-If /dev/1/2 already attached, should I fail?

Follow the same logic detailed in resmgr_attach/_RESMGR_FLAG_DIR – no
dir beneath a file.
If /dev/1/2 is a dir and you want to attach /dev/1 as a file, then yes
it should fail. Otherwise it seems legal to me.

Except that is a policy which is suggested to programmers but not
a rule actually enforced. If you want to do something odd like
that (put a file in the same location as a directory), you can,
the system won’t stop you.

OK.

-If /dev/ already attached, should I fail?
Clearly not.

Why not … /dev as a “directory” resource manager could be
providing an instance of /dev/1, and it may be a conditional
file so that the path manager has no way of guaranteeing if
that file exists in any atomic fashion.

Yes, you’re quite right. But if UNIQUE means fail in this case, it
would decimate the usefulness of UNIQUE. How could we then build a
system with your /dev (which has no intention of providing /dev/widget)
together with my /dev/widget and still prevent an accidental second
instatiation of widget? And the fact /dev may conditionally provide
anything just further confounds any effort to support this
interpretation.

Let’s carry out the scenario where UNIQUE does not mean fail for this
case.
If widget used _RESMGR_FLAG_BEFORE and is started after the /dev
dir-resmgr we’d be OK for the moment, right? i.e. There’d be only one
widget resmgr and it’ll handle “/dev/widget”. But how do we stay above
other (subsequent) dir resmgrs? Do we need a flag:
_RESMGR_FLAG_ALWAYS_BEFORE_DIRS
guarantees that resmgr will be before all dir resmgrs
can not be used with _RESMGR_FLAG_DIR

BTW: Isn’t this a problem that HA has to solve?

The problem is that the _RESMGR_FLAG_UNIQUE would only make sense
in the case where you don’t specify _RESMGR_FLAG_DIR, and the only

I’m not sure if I should agree with this. Isn’t this just a sub-class
of your first case?

If I attach a name /dev/1 with (_RESMGR_FLAG_DIR | _RESMGR_FLAG_UNIQUE)
it should fail if /dev/1 exists as either a dir or a file.

But if /dev/1/2 already exists as a file, I don’t see a problem.

The question here is what is the purpose of the UNIQUE
flag. Is it to guarantee that there is no manager who
is already registered at a given mountpoint. This is a

Yes, exactly.

condition which can easily be guaranteed since it is
entirely within the realm of the path manager.

If the purpose is to guarantee that there is nothing else
in the system which is using that “path” before we perform
an attach (ala O_EXCL), then regardless of how much effort
we go to, the path manager can make no such guarantees. If
it can’t be guaranteed then it is of no use to anyone.

I’d be willing to concede to the validity and usefullness of
the first case, but not to the second.

We’re in sync.

Additional food for thought is to consider what guarantees
one would expect to have about the meaning of the UNIQUE
mountpoint. Would this forbid others (non-unique) from
mounting on this path?

Perhaps “UNIQUE” is not the best name for such a flag…

But to answer your question, it depends on how you want to assign
responsibility for preserving UNIQUEness.

I’m mainly looking for a solution to preventing multiple instatiation of
a resmgr. So from the perspective of that problem, either
interpretation of the UNIQUE flag would have the same result – I could
rest assured the second attempt would fail. The question becomes:
Should the flag be used to allow other resmgrs to [optionally] honor
uniqueness (in which case the second resmgr would [could] back off)? Or
should the flag be used for the first resmgr to “trademark” the name (in
which case attempts from subsequent resmgrs would be rejected)?

Or should there be both UNIQUE and TRADEMARK flags?

-david

[system]

David Alessio <david.alessio@hsa.hitachi.com> wrote:

thomasf@qnx.com > wrote:

David Alessio <> david.alessio@hsa.hitachi.com> > wrote:
thomasf@qnx.com > wrote:

I want to attach a name /dev/1

-If /dev/1 already attached, it is clear I should fail.
Yes

-If /dev/1/2 already attached, should I fail?

Follow the same logic detailed in resmgr_attach/_RESMGR_FLAG_DIR – no
dir beneath a file.
If /dev/1/2 is a dir and you want to attach /dev/1 as a file, then yes
it should fail. Otherwise it seems legal to me.

Except that is a policy which is suggested to programmers but not
a rule actually enforced. If you want to do something odd like
that (put a file in the same location as a directory), you can,
the system won’t stop you.

OK.

-If /dev/ already attached, should I fail?
Clearly not.

Why not … /dev as a “directory” resource manager could be
providing an instance of /dev/1, and it may be a conditional
file so that the path manager has no way of guaranteeing if
that file exists in any atomic fashion.

Yes, you’re quite right. But if UNIQUE means fail in this case, it
would decimate the usefulness of UNIQUE. How could we then build a
system with your /dev (which has no intention of providing /dev/widget)
together with my /dev/widget and still prevent an accidental second
instatiation of widget? And the fact /dev may conditionally provide
anything just further confounds any effort to support this
interpretation.

Let’s carry out the scenario where UNIQUE does not mean fail for this
case.
If widget used _RESMGR_FLAG_BEFORE and is started after the /dev
dir-resmgr we’d be OK for the moment, right? i.e. There’d be only one
widget resmgr and it’ll handle “/dev/widget”. But how do we stay above
other (subsequent) dir resmgrs? Do we need a flag:
_RESMGR_FLAG_ALWAYS_BEFORE_DIRS
guarantees that resmgr will be before all dir resmgrs
can not be used with _RESMGR_FLAG_DIR

BTW: Isn’t this a problem that HA has to solve?

What you have to remember is that size (or length in this case)
matters in terms of the “priority” or ordering of the name resolution.
If we have two managers operating with no ordering flags:

Server 1: /dev
Server 2: /dev/widget

and the /dev server also provides a “widget” file (/dev/widget).
The resolution process will always resolve to Server 2 first
because it is the longest mountpoint match, then to Server 1
since as a directory it might manifest the file “widget”.

As such there is no need for a _RESMGR_FLAG_ALWAYS_BEFORE_DIRS
flag. The BEFORE/AFTER/OPAQUE flags are only relevant when
there are several servers attached with the same mount point,
regardless if it is a filesystem or a device resource manager.

The problem is that the _RESMGR_FLAG_UNIQUE would only make sense
in the case where you don’t specify _RESMGR_FLAG_DIR, and the only

I’m not sure if I should agree with this. Isn’t this just a sub-class
of your first case?

If I attach a name /dev/1 with (_RESMGR_FLAG_DIR | _RESMGR_FLAG_UNIQUE)
it should fail if /dev/1 exists as either a dir or a file.

But if /dev/1/2 already exists as a file, I don’t see a problem.

The question here is what is the purpose of the UNIQUE
flag. Is it to guarantee that there is no manager who
is already registered at a given mountpoint. This is a

Yes, exactly.

condition which can easily be guaranteed since it is
entirely within the realm of the path manager.

If the purpose is to guarantee that there is nothing else
in the system which is using that “path” before we perform
an attach (ala O_EXCL), then regardless of how much effort
we go to, the path manager can make no such guarantees. If
it can’t be guaranteed then it is of no use to anyone.

I’d be willing to concede to the validity and usefullness of
the first case, but not to the second.

We’re in sync.


Additional food for thought is to consider what guarantees
one would expect to have about the meaning of the UNIQUE
mountpoint. Would this forbid others (non-unique) from
mounting on this path?

Perhaps “UNIQUE” is not the best name for such a flag…

I agree, if it were to be implemented, it would most likely
take on the name _RESMGR_FLAG_EXCL, modelling after the
O_EXCL open mode which most programmers will be familiar
with.

But to answer your question, it depends on how you want to assign
responsibility for preserving UNIQUEness.

I’m mainly looking for a solution to preventing multiple instatiation of
a resmgr. So from the perspective of that problem, either
interpretation of the UNIQUE flag would have the same result – I could
rest assured the second attempt would fail. The question becomes:
Should the flag be used to allow other resmgrs to [optionally] honor
uniqueness (in which case the second resmgr would [could] back off)? Or
should the flag be used for the first resmgr to “trademark” the name (in
which case attempts from subsequent resmgrs would be rejected)?

Or should there be both UNIQUE and TRADEMARK flags?

My personal opinion is that the normal file operations
of the world work just fine with O_EXCL type of operation.
If this were present it would no doubt suit the needs of
developers like yourself. Any additional work to reject
other attaches (malicious or not) would be pushed to the
application since an attach of the mythical EXCL flag
in addition to BEFORE on a properly configured system
would guarantee exclusive access to that name.

Good discussion. All taken under advisement and consideration.

Thanks,
Thomas

Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf

[David_Alessio]

thomasf@qnx.com wrote:

David Alessio <> david.alessio@hsa.hitachi.com> > wrote:
thomasf@qnx.com > wrote:

David Alessio <> david.alessio@hsa.hitachi.com> > wrote:
thomasf@qnx.com > wrote:

I want to attach a name /dev/1

-If /dev/1 already attached, it is clear I should fail.
Yes

-If /dev/1/2 already attached, should I fail?

Follow the same logic detailed in resmgr_attach/_RESMGR_FLAG_DIR – no
dir beneath a file.
If /dev/1/2 is a dir and you want to attach /dev/1 as a file, then yes
it should fail. Otherwise it seems legal to me.

Except that is a policy which is suggested to programmers but not
a rule actually enforced. If you want to do something odd like
that (put a file in the same location as a directory), you can,
the system won’t stop you.

OK.

-If /dev/ already attached, should I fail?
Clearly not.

Why not … /dev as a “directory” resource manager could be
providing an instance of /dev/1, and it may be a conditional
file so that the path manager has no way of guaranteeing if
that file exists in any atomic fashion.

Yes, you’re quite right. But if UNIQUE means fail in this case, it
would decimate the usefulness of UNIQUE. How could we then build a
system with your /dev (which has no intention of providing /dev/widget)
together with my /dev/widget and still prevent an accidental second
instatiation of widget? And the fact /dev may conditionally provide
anything just further confounds any effort to support this
interpretation.

Let’s carry out the scenario where UNIQUE does not mean fail for this
case.
If widget used _RESMGR_FLAG_BEFORE and is started after the /dev
dir-resmgr we’d be OK for the moment, right? i.e. There’d be only one
widget resmgr and it’ll handle “/dev/widget”. But how do we stay above
other (subsequent) dir resmgrs? Do we need a flag:
_RESMGR_FLAG_ALWAYS_BEFORE_DIRS
guarantees that resmgr will be before all dir resmgrs
can not be used with _RESMGR_FLAG_DIR

BTW: Isn’t this a problem that HA has to solve?

What you have to remember is that size (or length in this case)
matters in terms of the “priority” or ordering of the name resolution.

You’re right, I do need to remember that! Thanks.

If we have two managers operating with no ordering flags:

Server 1: /dev
Server 2: /dev/widget

and the /dev server also provides a “widget” file (/dev/widget).
The resolution process will always resolve to Server 2 first
because it is the longest mountpoint match, then to Server 1
since as a directory it might manifest the file “widget”.

As such there is no need for a _RESMGR_FLAG_ALWAYS_BEFORE_DIRS
flag. The BEFORE/AFTER/OPAQUE flags are only relevant when
there are several servers attached with the same mount point,
regardless if it is a filesystem or a device resource manager.

The problem is that the _RESMGR_FLAG_UNIQUE would only make sense
in the case where you don’t specify _RESMGR_FLAG_DIR, and the only

I’m not sure if I should agree with this. Isn’t this just a sub-class
of your first case?

If I attach a name /dev/1 with (_RESMGR_FLAG_DIR | _RESMGR_FLAG_UNIQUE)
it should fail if /dev/1 exists as either a dir or a file.

But if /dev/1/2 already exists as a file, I don’t see a problem.

The question here is what is the purpose of the UNIQUE
flag. Is it to guarantee that there is no manager who
is already registered at a given mountpoint. This is a

Yes, exactly.

condition which can easily be guaranteed since it is
entirely within the realm of the path manager.

If the purpose is to guarantee that there is nothing else
in the system which is using that “path” before we perform
an attach (ala O_EXCL), then regardless of how much effort
we go to, the path manager can make no such guarantees. If
it can’t be guaranteed then it is of no use to anyone.

I’d be willing to concede to the validity and usefullness of
the first case, but not to the second.

We’re in sync.


Additional food for thought is to consider what guarantees
one would expect to have about the meaning of the UNIQUE
mountpoint. Would this forbid others (non-unique) from
mounting on this path?

Perhaps “UNIQUE” is not the best name for such a flag…

I agree, if it were to be implemented, it would most likely
take on the name _RESMGR_FLAG_EXCL, modelling after the
O_EXCL open mode which most programmers will be familiar
with.

This would be Perfect! And it carries with it the legitimacy
established by the time-honored O_EXCL. I understand your “if”
qualification. But any counter argument would also be an attack on
O_EXCL and, in the absence of a better solution, _RESMGR_FLAG_EXCL
should be ease to defend.

But to answer your question, it depends on how you want to assign
responsibility for preserving UNIQUEness.

I’m mainly looking for a solution to preventing multiple instatiation of
a resmgr. So from the perspective of that problem, either
interpretation of the UNIQUE flag would have the same result – I could
rest assured the second attempt would fail. The question becomes:
Should the flag be used to allow other resmgrs to [optionally] honor
uniqueness (in which case the second resmgr would [could] back off)? Or
should the flag be used for the first resmgr to “trademark” the name (in
which case attempts from subsequent resmgrs would be rejected)?

Or should there be both UNIQUE and TRADEMARK flags?

My personal opinion is that the normal file operations
of the world work just fine with O_EXCL type of operation.
If this were present it would no doubt suit the needs of
developers like yourself. Any additional work to reject
other attaches (malicious or not) would be pushed to the
application since an attach of the mythical EXCL flag
in addition to BEFORE on a properly configured system
would guarantee exclusive access to that name.

Agreed.

Good discussion. All taken under advisement and consideration.

That’s all I can ask. In the meantime, I’ll hold out hope that we don’t
run out of major numbers…

Thank you,
-david