|
Chris Chiesa
|
Resource Manager info needed
|
|
Chris Chiesa
04/12/2010 6:31 PM
post51494
|
Resource Manager info needed
(This is long. If you want to rush through it, read just the first and last paragraphs.)
I appear to need more and different information about “writing a resource manager” than appears in the official QNX
Neutrino manual of that name. Has anyone here perhaps compiled his/her personal gleanings / learnings “above and
beyond” that manual, into a form that he/she would be willing to share? Either posting here, or somehow arranging to
send directly to me, would be of interest.
Meanwhile, some thoughts on SOME of the more-and-different information I would like to have. Note that the following is
not exhaustive; I have plenty more where this comes from. For those who don’t feel like wading through three pages’
worth of frustration, I do have a specific question about something I’d like to implement, in the very last paragraph;
please at least skip to that and see if you can shed any light.
First, I’m handicapped by not quite knowing the proper terminology for talking about the various topics and entities
involved. For just one example--what exactly do I call the “thing that appears in the filesystem, that another program
can open() by name, and that looks/acts (we hope) like a regular file, but which is ‘really’ an access point to a
Resource Manager?” Is it simply called a “filesystem entry?” Something else? What do I call the “other end of
that same thing, as seen from/by the interior of my Resource Manager code?” I.e. “each one of these ‘things’ has
its own associated OCB, but the ‘thing’ itself is called a ____.” I have at hand a Resource Manager written “before
my time” by others, that natively supports a single thing-that-looks-like-a-file-to-the-outside-world, but to which I
have recently added support for a second thing-that-looks-like-a-file-to-the-outside-world. That’s a heck of a
mouthful and I’d like a simpler, shorter, noun to use instead of “thing-that-looks-like-a-file-to-the-outside-world.”
This may actually require TWO terms: one for what the outside world sees, and one for what the code works with. “
This code maintains two ____s, one for [purpose A] and the other for [purpose B]. These appear to the outside world as
____s that look-and-act like regular files.” Help me fill in the blanks. This is just the most glaring of several
trouble spots I have in trying to communicate with others on the topic of Resource Managers.
Second, I’d really like to see a bit more high-level introductory material. I suspect the authors think they’ve
already given this in the section on “The Bones of a Resource Manager” – but that text describes only “what happens
(when a client reads a [thing we’re maintaining that looks like a file],” not what the actual relationships are among
the various pieces-and-parts of a resource manager. I’d like something along the lines of, “in order to create a
functioning Resource Manager, you’ll have to do the following at minimum: a) populate a file attributes structure; b)
populate an iofuncs structure; c) “attach” to a path in the filesystem. You can do most of that very simply, using
mostly routines that already exist in the Resource Manager library, or for finer control can override or replace a
partial layer, a whole layer, or multiple layers of the library with your own code.” Then I’d want some exposition,
of course, on how to accomplish all that – at a high level, that is: NOT in terms of code examples and call-this-
function. I can blind-copy example code ‘til the cows come home, but if I don’t know what the various statements,
functions, arguments, etc. are intended to ACCOMPLISH I can’t “take it from there” in any meaningful fashion. Line-
by-line exposition after-the-fact is better than nothing, but I’d really like to see the high-level view – FIRST, if
possible, but at SOME point at least.
Next, I’d like to see a list of ALL POSSIBLE “standard I/O functions” that a Resource Manager might be expected/
required to handle (exclusive of Pulses and...
View Full Message
|
|
|
|
|
|
David Sarrazin
|
RE: Resource Manager info needed
|
|
David Sarrazin
04/13/2010 1:23 AM
post51503
|
RE: Resource Manager info needed
> -----Original Message-----
> From: Chris Chiesa [mailto:community-noreply@qnx.com]
> Sent: April 12, 2010 6:32 PM
> To: ostech-core_os
> Subject: Resource Manager info needed
>
>
> (This is long. If you want to rush through it, read just the
> first and last paragraphs.)
>
> I appear to need more and different information about
> “writing a resource manager” than appears in the official QNX
> Neutrino manual of that name. Has anyone here perhaps
> compiled his/her personal gleanings / learnings “above and
> beyond” that manual, into a form that he/she would be willing
> to share? Either posting here, or somehow arranging to send
> directly to me, would be of interest.
>
> Meanwhile, some thoughts on SOME of the more-and-different
> information I would like to have. Note that the following is
> not exhaustive; I have plenty more where this comes from.
> For those who don’t feel like wading through three pages’
> worth of frustration, I do have a specific question about
> something I’d like to implement, in the very last paragraph;
> please at least skip to that and see if you can shed any light.
>
> First, I’m handicapped by not quite knowing the proper
> terminology for talking about the various topics and entities
> involved. For just one example--what exactly do I call the
> “thing that appears in the filesystem, that another program
> can open() by name, and that looks/acts (we hope) like a
> regular file, but which is ‘really’ an access point to a
> Resource Manager?” Is it simply called a “filesystem entry?”
This is called a "file". Each named entity (or "file") will have an iofunc_attr_t associated with it.
> Something else? What do I call the “other end of that same
> thing, as seen from/by the interior of my Resource Manager
> code?” I.e. “each one of these ‘things’ has its own
> associated OCB, but the ‘thing’ itself is called a ____.”
When a file is opened, an iofunc_attr_t needs to be allocated by the IO_OPEN handler (assuming that same file is not
already opened, and that you're doing a filesystem, where you've got many files under one resmgr_attach() point). Then,
for each time the file is opened, an iofunc_ocb_t is allocated, which holds any resmgr information which is specific to
the file descriptor (things like the ioflags passed to open(), and the offset of the file descriptor).
> I
> have at hand a Resource Manager written “before my time” by
> others, that natively supports a single
> thing-that-looks-like-a-file-to-the-outside-world, but to
> which I have recently added support for a second
> thing-that-looks-like-a-file-to-the-outside-world. That’s a
> heck of a mouthful and I’d like a simpler, shorter, noun to
> use instead of
> “thing-that-looks-like-a-file-to-the-outside-world.” This
> may actually require TWO terms: one for what the outside
> world sees, and one for what the code works with. “This code
> maintains two ____s, one for [purpose A] and the other for
> [purpose B]. These appear to the outside world as ____s that
> look-and-act like regular files.”
There isn't really an internal name, perhaps OCB is the closest thing. Externally they really are true "files".
> Help me fill in the
> blanks. This is just the most glaring of several trouble
> spots I have in trying to communicate with others on the
> topic of Resource Managers.
>
> Second, I’d really like to see a bit more high-level
> introductory material. I suspect the authors think they’ve
> already given this in the section on “The Bones of a Resource
> Manager” – but that text describes only “what happens (when a
> client reads a [thing we’re maintaining that looks like a
> file],” not what the actual...
View Full Message
|
|
|
|
|
|
Chris Chiesa
|
Re: RE: Resource Manager info needed
|
|
Chris Chiesa
04/13/2010 3:26 PM
post51604
|
Re: RE: Resource Manager info needed
David,
Thank you for your swift response. I appreciate it. My responses to yours follow, along with another batch of
questions from today’s work.
> > [W]hat exactly do I call the
> > “thing that appears in the filesystem, that another program
> > can open() by name, and that looks/acts (we hope) like a
> > regular file, but which is ‘really’ an access point to a
> > Resource Manager?” Is it simply called a “filesystem entry?”
> This is called a "file". Each named entity (or "file") will have an iofunc_attr_t
> associated with it.
So even if it’s “really” a FIFO or a socket or whatever, it’s still called a “file?” Okay, thanks.
> > Something else? What do I call the “other end of that same
> > thing, as seen from/by the interior of my Resource Manager
> > code?” I.e. “each one of these ‘things’ has its own
> > associated OCB, but the ‘thing’ itself is called a ____.”
> When a file is opened, an iofunc_attr_t needs to be allocated by the IO_OPEN
> handler (assuming that same file is not already opened, and that you're doing a
> filesystem, where you've got many files under one resmgr_attach() point). Then,
> for each time the file is opened, an iofunc_ocb_t is allocated, which holds any
> resmgr information which is specific to the file descriptor (things like the ioflags
> passed to open(), and the offset of the file descriptor).
Hm… I thought the iofunc_attr_t was created once, by me, and passed to resmgr_attach(), and that it was the
iofunc_ocb_t that was created anew in the IO_OPEN handler. *sigh* Looking now at the Library Reference, I see I was
probably thinking of the io_funcs argument, which is a resmgr_iofuncs_t. *sigh* I have a hard time keeping all the
various “attr” etc. structs straight—hence my dream of a diagram that shows the relationships amongst all these
things.
Re the iofunc_attr_t you mention, then – does its address end up being what I find in Ocb->attr when inside e.g. my
Read handler?
> There isn't really an internal name, perhaps OCB is the closest thing. Externally
> they really are true "files".
Okay. It's disappointing that there's no proper (as I see it) term, but thanks for at
least giving me a definitive answer.
> All of the standard information describing a file is in the iofunc_attr_t.
> Iofunc_stat() will convert the data from an iofunc_attr_t to a "struct stat".
Um, okay – so how do I return it to the caller? Somebody somewhere has to “construct a message and reply to the
IO_STAT message”_with appropriate content_; exactly how do I make that happen? This isn't really crucial, but it
would be nice if one could “ls –l” my file and get an accurate idea of how many
bytes stand to be readable from it at any given time.
> > At least for a “regular file” I have a general idea
> > of what values to put in, but I could use some info (or at
> > least recommendations) for what values would be appropriate
> > if my “file” is actually a directory or a FIFO or something.
> That is in the "mode" field of struct stat.
Do you mean
Mode_t st_mode
? That isn’t AT ALL what I was asking about. What sorts of things go in e.g. the group ID, user ID, device ID, number
of hard links, etc. etc. etc. fields? Are you saying that ABSOLUTELY EVERYTHING ELSE is filled in FOR me somehow? By
whom (what software component)? Where does THAT entity/component get the “right information?” I’m afraid I’m
still clueless here.
> Messages come into the channel, and are picked off in priority order by threads in
> the pool. A thread handles the single message (IO_OPEN, IO_CLOSE, IO_READ,
> etc.), and then replies, and blocks again on the channel. If an application calls
> read() in a loop, it's entirely possible that each call to read() is handled by a
> different...
View Full Message
|
|
|
|
|
|
Steve Reid
|
RE: Resource Manager info needed
|
|
Steve Reid
04/13/2010 3:14 PM
post51600
|
RE: Resource Manager info needed
Thanks for the feedback and questions, Chris. The Writing a Resource
Manager book is still fairly new, so it's good to know what we need to
do to improve it. I'm following this thread, and I'll incorporate into
the book whatever tips and information that people provide.
Steve Reid (stever@qnx.com)
Technical Editor
QNX Software Systems
|
|
|
|
|
|
