Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File handling updates #4

Open
gdarcy opened this issue Apr 19, 2010 · 6 comments
Open

File handling updates #4

gdarcy opened this issue Apr 19, 2010 · 6 comments

Comments

@gdarcy
Copy link
Contributor

gdarcy commented Apr 19, 2010

Updated code now enables you to manipulate files directly as an alternative to using the fdt system. Currently only supports opening new files and closing files. To what extent should we work to abstract a layer over the fdt code?

@gdarcy
Copy link
Contributor Author

gdarcy commented Apr 19, 2010

Further abstractions duly committed.

@gdarcy
Copy link
Contributor Author

gdarcy commented Apr 26, 2010

Any reason not to start working on write?

Things that appear necessary for it:

  • Necessary handling for STDOUT as a write target
  • Implementation of pwrite for ext2

    Anything I'm missing?

  • @giannitedesco
    Copy link
    Owner

    Heh, very much:

    • floppy driver support for write
    • ext2 pwrite includes block allocation and metadata updates
    • how to co-ordinate file-size changes and consequent block allocations with writing blocks vs. page cache and making sure everything happens in right order
    • writes to page-cache can trigger reads if not overwriting a whole page
    • kernel thread to flush page-cache periodically
    • perhaps even vm-balancing code to squeeze page-cache when other allocations fail

    IOW, read side of vfs is waaay less than half the work!

    stdin/stdout are total hacks at the moment and require a character device layer at the very least, and a terminal implementation ideally :)

    Still too tied up working on qemu things in citrix as of yet, just committed first cut of fork() implementation though :)

    @gdarcy
    Copy link
    Contributor Author

    gdarcy commented Jun 11, 2010

    Heh, there was me hoping for an easy job :P Once I've finished and committed the kernel/user refactor, I'll rough in the kernel/user write support and start drilling down towards the floppy driver.

    At this point, I figure it's probably more useful for me to code the wrong thing than to code nothing -- it's ages since I did anything on here, and it took me a while to get back up to speed.

    @giannitedesco
    Copy link
    Owner

    Yeah, a lot of the bits for write support are orthogonal, eg. low level floppy disk writes and block layer stuff like queuing.... I'm not even sure myself how it'll all link in to the page-cache. An ATA hard-disk and ATAPI CD-ROM driver would also come in handy :)

    @giannitedesco
    Copy link
    Owner

    Actually kernel/read.c could do with being re-worked to use the page-cache. Rather than call pread directly just do a loop to pull everything in to page-cache and then kernel_read() would memcpy it in to the buffer and sys_read would copy_to_user it.

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    None yet
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants