Lindsey Kuper (lindseykuper) wrote,
Lindsey Kuper

All of us together/in the same device

I'm working on the last homework assignment (which doubles as the final) for the OS course I'm taking, which is to write a toy filesystem. It's not a kernel module or anything, just a user-space thing, so I suppose it's less a filesystem than a database, really. Running the provided test program creates a big1 ol' monolithic fs.dat within which one's "files" live.

$ file fs.dat
fs.dat: data

"data". Damn straight. It is not XML. It is not JSON. Regarding its endianness no information is to be had. It is not UTF-anything. There is no name for what it is! But there's stuff in there that can be thought of as representing files, and it's possible to read them and write them and create and delete and all of that. Or it will be, notionally, as soon as I implement the ability to do that stuff. So far, all you can really do is "format" the thing, which sets up a superblock, an inode for the root directory, and a list of free blocks. That part works. I think. If you've ever formatted a floppy disk, I fancy this process as being a lot like that. Except, uh, less sophisticated. And on a smaller scale.

The assignments that we turn in have to compile and run on Linux, and using my Mac to test my code has gotten a little bit less feasible with each one. At first, my code ran on both without issue. Later, things started to get #ifdeffy, or sometimes the code would run on both but produce different results. With the filesystem assignment, I'm officially giving up on trying to make it portable.2 On my Mac, the test program promptly segfaults, and I'm not going to worry about figuring out why.

On Linux, though! I just tried it out and it's awesome. The formatting seems to work, and then the test program continues running, thinking it's creating files and writing to them and so forth. Except! None of the functions that do those things have been implemented yet; they're there, but they don't do anything at all, except sometimes creating some dummy objects on the stack and returning them, to make the types -- such as they are -- work out. So, the program runs, and some bytes get copied around, and when the test program eventually prints out what it thinks it has "read" from what it thinks was a "file", it prints this:

?Y?h8???????????9??h@@0?h8/??h8Linux?@@{?h8ui csug.1?h8??h8?)?h8XkU?*?kU?*?????@??w?@?\?h80?????????w?@?}?h8?kU?*x86_64?kU?*?\?h8X????Y?h8(none)@ PP@ P?????g?h8?ıh8?@????? @@L?h8?@????????ıh8? @P@?@?@??????????????????????????:???U???h???t???7???C???_???????????????????!???J???R???d???s??????????????????d@@8 ?@ f? bb????x86_64./fsHOSTNAME=csug01.csuglab.cornell.eduTERM=xterm-colorSHELL=/bin/bashHISTSIZE=1000SSH_CLIENT=::ffff: 54565 22OLDPWD=/home/lak223/cs4410SSH_TTY=/dev/pts/7USER=lak223LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:KDEDIR=/usrMAIL=/var/spool/mail/lak223PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/binINPUTRC=/etc/inputrcPWD=/home/lak223/cs4410/assignments/4LANG=en_US.UTF-8SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpassKRB5CCNAME=FILE:/tmp/krb5cc_49766_UKYjQrSHLVL=1HOME=/home/lak223LOGNAME=lak223SSH_CONNECTION=::ffff: 54565 ::ffff: 22LESSOPEN=|/usr/bin/ %sG_BROKEN_FILENAMES=1_=./

which is...some interesting-looking garbage, followed by what appear to be my bash environment variables. How did that get there?! Dude! Also, now you know my Cornell username.

I suppose I should do the rest of the assignment now or something, and fix this bug. But -- isn't it fun, having something break in a weird and interesting way? Don't get me wrong -- I don't think I would want to try to build large, portable, reliable, secure systems like this. But for hacking on your own, which bug would would you rather have -- this, or some boring-ass CantDoThatException? Right now my vote's for this.

  1. Where by "big" I mean "256 K".
  2. Between this and running Ubuntu at work and loving it, I'm starting to feel just a little disillusioned with OS X. I have an Ubuntu box at home that I've been neglecting because it's easier to just use my Mac, where things Just Work. But I think that when I get back home in the fall I'll upgrade to Limpid Lemur or whatever they're on now and start using it more regularly. These days, things actually Just Work on Ubuntu, too -- and Ubuntu doesn't have several competing package management systems, all of which are mediocre.
Tags: cs4410, programming

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded