[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Started looking at open.c
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.
I somehow forgot to CC this to the list last time. so I am CCing it now.
what's the next step?
I'll see you in irc land if I have more questions.
thanks again Ethan,
ajay.
> -----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/
>