tornewuff
FatFS module
Develop and add a module to access to FAT filesystems using the FatFS library so we can have a basic filesystem where to start working on. Maybe it's not the perfect one (I would prefer to develop a custom RAM-based ObjectStorage that automatically does a persistent store of the Python objects, deleting any conception about volumes or storages or anything), but it's enough for the current stage of the project. Info about how to compile it for Raspberry Pi on their forums.
Regarding to the API, we can use the FatFS native one, or use the PyFilesystem project (I used it in the past and like the concept, but dislike their focus on high level inexperienced users making it dificult and very ineficient for low level developers), or develop our own one, putting atention on versatility in a similar way PyFilesystem or FUSE try to achieve, eficiency and pythonic style (for example, seeing and accessing directories as dict objects, or more agresively, directly as plain set objects, that's more close to the reality and low level concepts).
You're jumping the gun significantly here; a filesystem is a lot of work away. First there needs to be a driver framework, a block device framework, and an MMC/SD stack (which will realistically require interrupt support as well) :)
Also, FatFS is a C library; a filesystem is a great example of something that could and should be implemented entirely in Python here.
You're jumping the gun significantly here; a filesystem is a lot of work
away. First there needs to be a driver framework, a block device framework, and an MMC/SD stack (which will realistically require interrupt support as well) :)
This makes sense if we are thinking about doing it once-for-all, but my sugestion about using FatFS is about to have something that allow to store files and try to pass all the CPython tests, and later from there start digging out the C parts and using substitutes (first the filesystem, later the access to the block device, later the access to the hardware ports and interrupts...) until we get all the stack developed in pure Python. On my x86 port of PyMite I was able to manage hardware interrupts in Python converting them previously to some kind of events Python objects in the C side just for optimization and easier management and it was easy to do... :-)
Also, FatFS is a C library; a filesystem is a great example of something
that could and should be implemented entirely in Python here.
I already did it (https://github.com/piranna/PirannaFS), so I know what we are talking about here ;-)
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux
There's not really any need to store files currently, though. What files would there be? Passing the CPython tests is also not interesting at all; it's an unmodified copy of CPython, there's not really any point in testing the interpreter.
I'm not at all interested in using any more C code even on a temporary basis. The point is to come up with a clean design from the ground up that's declarative, object-oriented, and feels "pythony". A filesystem is quite a long way off; I'm more interested in having a display driver and input drivers to make it usable as an interactive terminal without using the limited serial debug code.
There's not really any need to store files currently, though. What files
would there be?
For example, the full Python standard library :-) Batteries included!!! :-P
Passing the CPython tests is also not interesting at all; it's an unmodified copy of CPython, there's not really any point in testing the interpreter.
Yes, you are right, it was more of "hey, you can do everything you already do with your standard Python" thing :-)
I'm not at all interested in using any more C code even on a temporary
basis. The point is to come up with a clean design from the ground up that's declarative, object-oriented, and feels "pythony". A filesystem is quite a long way off; I'm more interested in having a display driver and input drivers to make it usable as an interactive terminal without using the limited serial debug code.
I totally agree on, we have the same perspective on this point (although maybe not so much regarding to the temporal code when needed...), so maybe this issue could be closed.
By the way, according to this, I already see the serial C driver as a temporal code... Maybe developing a compatible "driver" for PySerial and init it from inside the virtual machine to have a remote, interactive Python shell would be, as a friend of mine says, a good way to "eat our own dog food": hardware interruptions, port access, on-boot script... ;-)
For port access I've found the PortIO package ( https://pypi.python.org/pypi/portio/0.5, http://portio.inrim.it/) really useful and easy to use... :-)
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux
If you want the rest of the standard library you can just drop it in the initial ramdisk for now; it already does this for a number of modules.
The C serial driver isn't temporary; it's a debugging facility. Replacing it with Python doesn't make a lot of sense because it's used to display the status if the interpreter crashes, amongst other things :) Nobody is going to want to interact with their device using a serial console in reality, so writing a higher level serial driver doesn't seem very interesting. As I said, the next thing that would be interesting is likely a display driver and some kind of input device to have a real console.
ARM doesn't have IO ports, everything is memory mapped, so there's no need for PortIO. PySerial also doesn't have the right kind of interface, I don't think; the goal is to design a consistent driver interface for many kinds of device, not to reproduce specific libraries used on hosted environments.