On Tue, Jul 01, 2003 at 09:33:36AM -0400, Pisupati, Ajay wrote:
> awesome. I understand a _lot_ better now.
> I guess my big confusion (as you so correctly indentified) was that I was
> thinking that somehow OF was opening a file rather than rawio driver. now
> that you explained it, it makes a lot more sense.
yes, except rawio opens devices only, the filesystem drivers will open
files, by reading raw devices which are handled by rawio.
> I somehow forgot to CC this to the list last time. so I am CCing it now.
better to just mail the list only, that way my threading doesn't get
mucked up. (minimalist skips sending me a post if im already in the
address lists)
> what's the next step?
hopefully some actual coded implementation.
> I'll see you in irc land if I have more questions.
ok
> thanks again Ethan,
thanks
> > -----Original Message-----
> > From: Ethan Benson [mailto:erbenson@alaska.net]
> > Sent: Tuesday, July 01, 2003 3:29 AM
> > To: Pisupati, Ajay
> > Subject: Re: Started looking at open.c
> >
> >
> > On Mon, Jun 30, 2003 at 03:37:56PM -0400, Pisupati, Ajay wrote:
> > > Ethan,
> > > appreciate the reply. Now I have more questions :) (sorry).
> >
> > thats fine. ask away. (try to come by irc when im around too, much
> > easier to explain these things in real time.)
> >
> > > is this sequence of events correct?
> > > 1. When I call the regular open function in *nix, it calls
> > the FS driver to
> > > open it
> >
> > more or less yes.
> >
> > > 2. the FS driver uses the help of the kernel to open the
> > file (create an
> > > open file object) and returns a fd to the calling program.
> >
> > mostly, i think the vfs takes care of building an inode structure and
> > file descriptor. but this isn't really important.
> >
> > > in our case, the prom-libc.open behaves the same way (from
> > your pseudo
> > > code):
> > > 1. client calls the pl_open function with
> >
> > no there is no such thing as pl_open (i know where you got this
> > confusion from, see later).
> >
> > its just open() with the same format as unix:
> > open(const char *name, int flags, mode_t mode);
> >
> > > ("device_partition,path_to_file",flags) info.
> > > 2. pl_open splits path into
> > > device_partition
> > > path_to_file (i am assuming absolute path for now)
> >
> >
> > it splits device and file, it doesn't split partition (thats part of
> > the device)
> >
> > so you get:
> >
> > hd:3
> > /etc/passwd
> >
> > > 3. using the device_partition info, pl_open now scans the
> > device_partition
> > > to determine the FS
> >
> > yes, using fs provided functions.
> >
> > > 4. once FS is determined, pl_open
> > > saves the FS_type in a variable
> > > allocates a new _fd struct
> > > passes the &_fd and the "device_partition,path_to_file"
> > to the FS
> > > driver to open it
> > > 4b. FS calls "correct open" function (see detour below) to
> > open the file.
> >
> > FS calls open("hd:3", O_RDONLY) the fs has to open the raw
> > partition block
> > device so it can parse the filesystem on there.
> >
> > > <detour>
> > > Here's where my confusion begins:
> > > [a] you call open again
> > > is this the same pl_open or one that is present in the
> > FS driver?
> > > [b] when you call open, you seem to be passing in only the
> > device_partition
> > > info and not the path_to_file info. is this intentional or
> > were you just
> > > saving on the typing?
> > > </detour>
> >
> > no i think your under the impression that OF can open files, it can't,
> > not unless your opening a file from a crippleware filesystem.
> >
> > lets go through the steps starting from within a filesystem driver:
> >
> > xfs_open("hd:3,/etc/passwd")
> > fd = open("hd:3", O_RDONLY);
> > read(fd, buf, 5);
> > if (strcmp(buf, "XFSB")
> > return -EFSCORRUPTED;
> > <stuff to verify /etc/passwd exists etc>
> > return 0;
> >
> > now what happens in response to xfs_open's open() call:
> >
> > open("hd:3", O_RDONLY)
> > if (!devicepath_filepath("hd:3"))
> > rawio_open("hd:3")
> > __fd->ihandle =
> > __1275_open("hd:0") <-- whole disk
> > parse_partition_stuff()
> > put partition offset
> > stuff in __fd
> > if everything is ok
> > return 0;
> >
> >
> > > 5. the "correct open" function calls rawio_open function
> > and hands off the
> > > path to it.
> >
> > there is no `correct open' only open(). open() needs to be smart
> > enough to do the right thing. basically (semi pseudocode):
> >
> > open.c:
> > int open(const char *name, int flags, ...)
> > {
> > if (!name)
> > return -EFAULT;
> >
> > /* not quite right syntax for this, but keep it simple for
> > demonstration purposes */
> > if (!devicepath_filepath(name)) {
> > /* no filename, must be a raw device we want to
> > open, eg hd:3 */
> > use rawio driver;
> > else if (!devicepath_devicenode(name)) {
> > /* no device, relative open from getpwd() */
> > else {
> > find a filesystem driver, see above.
> > }
> > }
> >
> >
> > > 6. rawio_driver (which interfaces w/ OF) returns the fd to
> > the "correct
> > > open" function
> >
> > no... open() creates a file descriptor structure, rawio just fills a
> > part of it with infos it needs later (an ihandle for example, which is
> > OF's form of file descriptor for its' OPEN method).
> >
> > > 7. the "correct open" (called by the FS driver) then
> > returns the fd to
> > > pl_open
> > > 8. pl_open returns the fd to client.
> >
> >
> > forget pl_open and this `correct open' thing.
> >
> > there is only one open(). everything uses it EXCEPT rawio. all
> > open() roads eventually lead back to rawio, rawio is man behind the
> > curtian doing the real work with low level prom interfaces.
> >
> > so if you open("hd:3", O_RDONLY) there is only one open() call, since
> > no filesystems are involved you go right to rawio.
> >
> > if you open("hd:3,/etc/passwd", O_RDONLY) there are TWO open() calls
> > the first is the client's request (for hd:3,/etc/passwd), the second
> > is the XFS filesystem driver's request for hd:3 (xfs will call
> > open("hd:3") which as you see above goes to rawio).
> >
> >
> >
> >
> >
> >
> > where you got confused was my getting ahead of myself and pointing out
> > that this design easily lets us port the whole shebang to any kind of
> > platform we want, be it OpenFirmware, anchient versions of Sun
> > OpenBoot, probably even x86 BIOS.
> >
> > what it also lets us do is `port' it to UNIX itself, so we can debug
> > it with usual tools like gdb, and not the painful `bazillion printf
> > and reboot horror' native OF debug session.
> >
> > the only problem with this is we use the function name open() just
> > like unix does so if we leave all the code as is, everything gets
> > bypassed:
> >
> > open("hd:3,/etc/passwd", O_RDONLY) -> glibc -> linux-kernel
> > -> return -ENOENT
> >
> > but we don't want that to go to the linux kernel, we want it to go to
> > prom-libc, now we could probably just not link to glibc and avoid this
> > problem, but then when we get down to the rawio implementation that
> > just uses unix syscalls (open()) we end up just calling ourself again
> > ;-)
> >
> > so what i was saying was for the userspace test version we could just
> > cheat and #define open plibc_open in everything EXCEPT rawio, that way
> > our code gets called everywhere except in rawio where we DO want the
> > linux kernels open() to happen. that also lets us just link to glibc
> > and not have to reinvent all the asm syscall glue. see in OF the low
> > level OPEN method is called __1275_open() in UNIX the low level OPEN
> > method is called open() which of course conflicts with the high level
> > open().
> >
> > clear now?
> >
> > --
> > Ethan Benson
> > http://www.alaska.net/~erbenson/
> >
--
Ethan Benson
http://www.alaska.net/~erbenson/
Attachment:
pgp00004.pgp
Description: PGP signature