[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Started looking at open.c

To: "'yaboot-devel@lists.penguinppc.org'" <yaboot-devel@lists.penguinppc.org>
Subject: RE: Started looking at open.c
From: "Pisupati, Ajay" <ajay.pisupati@pw.utc.com>
Date: Tue, 1 Jul 2003 15:20:23 -0400
that is what I am planning to do.  the code might be ugly, but, I'll try and
get it going.  once it starts, I think it is going to be a lot easier to
implement the other functions as well.  I am going to start w/ open.c unless
someone has better ideas.
ajay

> -----Original Message-----
> From: Ethan Benson [mailto:erbenson@alaska.net]
> Sent: Tuesday, July 01, 2003 2:48 PM
> To: 'yaboot-devel@lists.penguinppc.org'
> Subject: Re: Started looking at open.c
> 
> 
> 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/
>
Prev by Date: Re: Started looking at open.c
Next by Date: include GPL + code sharing ?
Previous by thread: Re: Started looking at open.c
Next by thread: include GPL + code sharing ?
Index(es):
- Date
- Thread