[Pgui-devel] porting effort
Hi all, I'd like to port picoGUI on my own operating system (http://mynos.sourceforge.net). At the moment DEPUI already works on mynos, but I have very few POSIX syscalls implemented. I'd like to have an idea of the *basic* posix syscalls picoGUI *needs* to run (signals calls? threads calls? select&ioctl?) Thank you very much! -- Cesare --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] still going
It's really been far too long since I worked on the Helio. I'd suggest finding someone else that's also working on the helio if possible, or maybe posting this to the uClibc or busybox mailing lists. On Wed, Jan 29, 2003 at 02:25:59AM +, Mark and Janice Juszczec wrote: > > Micah > > Just thought I'd drop you a line and let you know how its going. > > Got uClibc and compiled it. > Got busybox and compiled it using uClibc. > Put together a rom with uClibc, busybox and /dev & /etc from Matt Welland's > dist-helio-2. > > It will boot and gives me the "Freeing unused kernel memory: 48k freed" > and the 3 "attempt to access beyond end of device" messages. I read > somewhere to ignore this message "beyond end of device" message. Can you > (or anyone reading) confirm or deny? > > No shell prompt via minicom. lash and sh are compiled in and there are > links to them. > > How do I verify busybox init is really running? Any suggestions about how > to get a shell prompt? > > When I get a shell prompt I'll move on to compiling pgui and hammering away > at the pim. > > Mark > > _ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel -- Only you can prevent creeping featurism! --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] porting effort
On Wed, Jan 29, 2003 at 11:03:20AM -0500, Cesare Zavattari wrote: > Hi all, > I'd like to port picoGUI on my own operating system > (http://mynos.sourceforge.net). At the moment DEPUI already works on > mynos, but I have very few POSIX syscalls implemented. > I'd like to have an idea of the *basic* posix syscalls picoGUI *needs* to > run (signals calls? threads calls? select&ioctl?) > Thank you very much! Cool. PicoGUI will need, from the top of my head: - C standard library functions including the printf family, malloc and friends, and standard file I/O - Several miscellaneous functions including timers, shared memory, and directory tree traversal- fortunately much of this can be safely omitted, and it's all quarantined within the 'pgserver/os' directory. - BSD sockets. All the networking code in PicoGUI currently assumes BSD-compatible sockets, as also provided by Linux, IRIX, and (sort of) win32. This will be eliminated when the network code is refactored. This includes the use of select() to wait on multiple sockets and/or input devices. > > -- > Cesare > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel -- Only you can prevent creeping featurism! --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] porting effort
On Wed, 29 Jan 2003, Micah Dowty wrote: > Cool. thank you :) > PicoGUI will need, from the top of my head: > > - C standard library functions including the printf family, malloc and > friends, and standard file I/O ok > - Several miscellaneous functions including timers, shared memory, > and directory tree traversal- fortunately much of this can be safely > omitted, and it's all quarantined within the 'pgserver/os' directory. I'll take a look, thank you. > - BSD sockets. All the networking code in PicoGUI currently assumes > BSD-compatible sockets, as also provided by Linux, IRIX, and (sort of) > win32. This will be eliminated when the network code is refactored. > This includes the use of select() to wait on multiple sockets and/or > input devices. At the moment MyNOS have not a network layer (but it's in our plan). Is it possible to substitute the network layer with the mynos-core microkernel IPC (send/receive)? thank you very much! -- Cesare --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] still going
On Wed, 29 Jan 2003, Mark and Janice Juszczec wrote: > > Micah > > Just thought I'd drop you a line and let you know how its going. > > Got uClibc and compiled it. > Got busybox and compiled it using uClibc. > Put together a rom with uClibc, busybox and /dev & /etc from Matt Welland's > dist-helio-2. > > It will boot and gives me the "Freeing unused kernel memory: 48k freed" and > the 3 "attempt to access beyond end of device" messages. I read somewhere > to ignore this message "beyond end of device" message. Can you (or anyone > reading) confirm or deny? I did have a go a few months back to get the stuff from Matt Welland's site compiled and to run on the helio and the helio emulator. Can't quite remember where I got to but I do remember things often hanging at the freeing kernel memory stageI got pretty stuck trying to work out how the kernel gets from a single task running in kernel mode to the first task (sh) running in user mode. I haven't got much time atm but I would like to see the helio working - can you put your 'best attempt' tree on a site somewhere? I'll try and have a look at the w/end. Have you tried it with the emulator? I'd quite like to get that going sinc flashing the helio is such a pain. Cheers, Chris --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] porting effort
On Wed, Jan 29, 2003 at 12:14:54PM -0500, Cesare Zavattari wrote: > > At the moment MyNOS have not a network layer (but it's in our plan). Is it > possible to substitute the network layer with the mynos-core microkernel > IPC (send/receive)? Not yet; will be after the refactor, but that may take some months. But you *can* now replace it with unix sockets, would that be easier for you? (I know MyNOS is not Unix, but perhaps sockets are easier to emulate.) You can also link the pgserver (compiled as a library) directly to the application, that means in principle you would have only one single app, but perhaps your OS can get around this (perhaps you write an app that does its own multiplexing using microkernel rpc, that's what I was pondering to do for the Hurd before we came up with the new design). []s, |alo + -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/mailto:[EMAIL PROTECTED] pgp key: http://www.laranja.org/pessoal/pgp Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ GNU: never give up freedom http://www.gnu.org/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] porting effort
On Wed, Jan 29, 2003 at 09:30:47AM -0200, Lalo Martins wrote: > On Wed, Jan 29, 2003 at 12:14:54PM -0500, Cesare Zavattari wrote: > > > > At the moment MyNOS have not a network layer (but it's in our plan). Is it > > possible to substitute the network layer with the mynos-core microkernel > > IPC (send/receive)? > > Not yet; will be after the refactor, but that may take some months. But you > *can* now replace it with unix sockets, would that be easier for you? (I > know MyNOS is not Unix, but perhaps sockets are easier to emulate.) > > You can also link the pgserver (compiled as a library) directly to the > application, that means in principle you would have only one single app, but > perhaps your OS can get around this (perhaps you write an app that does its > own multiplexing using microkernel rpc, that's what I was pondering to do > for the Hurd before we came up with the new design). Yep, this would be one way around it until the refactoring- however, you would still need to disable the TCP/IP code. There's an option to disable the TCP/IP in pgserver's configuration, but it doesn't actually do anything yet :( Aside from actually doing the network code refactoring, this could be done with some liberal use of #ifdef in net/request.c > > []s, >|alo >+ > -- > Those who trade freedom for security >lose both and deserve neither. > -- > http://www.laranja.org/mailto:[EMAIL PROTECTED] > pgp key: http://www.laranja.org/pessoal/pgp > > Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ > GNU: never give up freedom http://www.gnu.org/ > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel -- Only you can prevent creeping featurism! --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
[Pgui-devel] The object model of the new generation
Hi Everybody, I have a subversion server set up for Neo-PicoGUI. It's linked to on picogui.org. No actual code there yet, but I've been laying out the directory structure and putting in some documentation. I've been working more on the design for the object model Neo-PicoGUI will use. Thanks to the great suggestions from Nathaniel (njs on IRC) I've researched using capabilities as a security model. The short explanation- there is no concept of user or process security like in a traditional system, just objects which grant particular capabilities. Everything hinges on objects using ID numbers that are unguessable, so in order to access an object you must obtain a reference to it. E is a spiffy language that's completely capability based. There's a good bit of documentation on it here: http://www.skyhunter.com/marcs/ewalnut.html The object model will handle memory management, security, and data types- it will be a library linked with all PicoGUI modules. This will include all pgserver components (only one copy of the library per process of course) and the C client library. Other client libraries should probably choose to reimplement the object model using their language's native OOP terminilogies. This library will probably be called libpok. (PicoGUI Object Kernel) It will borrow ideas from Python's C API and from E. Every object will have: - A reference count - A type, which could be a user-defined type or a custom type - Optionally, a capability - A pointer to type-specific data - A pointer to instance-specific data In objects that are used only within a single process, the capability is unnecessary. The capability will normally be fairly large- 128 bits is common. This is necessary to ensure they're unguessable. Within one process, this is irrelevant. Separate pointers to type- and instance-specific data allows a very cheap implementation of 'facets', which allow different levels of access to the same data. For example, an application could allow another to embed itself within the first by creating a facet of a widget that only allows attaching other widgets inside, and passing on a reference to that facet. The facet would only consist of the object structure itself, a capability, and new type-specific data. This structure would allow pretty much arbitrary data to be stored in the object kernel. Applications could store their own data in the kernel, so that if the kernel is equipped with facilities for storing persistent data or synchronizing to other kernels, the apps would benefit from them as well. Just some ideas- after I do some homework, research this some more, and stop being indecisive about the directory tree I might actually do some code ;) --Micah -- Only you can prevent creeping featurism! --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] porting effort
>> At the moment MyNOS have not a network layer (but it's in our plan). Is it >> possible to substitute the network layer with the mynos-core microkernel >> IPC (send/receive)? > > Not yet; will be after the refactor, but that may take some months. But > you *can* now replace it with unix sockets, would that be easier for > you? > (I know MyNOS is not Unix, but perhaps sockets are easier to emulate.) mmm... maybe it's better to add as soon as possible the network layer to MyNOS. We'd like to use the OSkit library for so. > You can also link the pgserver (compiled as a library) directly to the yes, but I'd like very much to have picoGUI full client-server architecture implemented. thank you :) -- Cesare --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
[Pgui-devel] Designing a more efficient protocol
Hi, Another consideration for the new object model, is in optimizing the wire protocol. Currently PicoGUI always requires a response for every request, and in order to create an object then set properties you have to wait for the object ID to be returned, then use that ID to set properties. The solution I was planning on using to solve this was having the client generate IDs rather than the server. In the old handle system, this would involve two handle spaces- a per-client space and a global space, with the server owning a mapping between the two. In the new capability system, it since the IDs are allocated randomly anyway it would just involve a cryptographically secure random number generator in the client. But, I don't like the idea of forcing the client library to know how to create new object IDs- if a better random number algorithm is invented, or the scheme changes entirely, clients shouldn't have to know. My latest wacky idea fo circumventing this is to make the network-transparent version of the RPC layer actually a very simple virtual machine. For example: - client creates an object, the ID is pushed onto a stack - client uses that ID to set some object properties - client asks for the ID to be sent back to it Or even more complex but still useful uses: - client retrieves the ID of a global object, for example a read-only list of server properties - client retrieves the ID of the "Operating System" key from that list - client asserts that the type of that object is a string - client asks that the object's contents be sent back to it In the object kernel, such a virtual machine for making queries would be very simple to implement. Creating a simple way of forming the queries would be harder. One method would be for every request the client makes that executes remotely, an identifier for that request is returned rather than a real answer. (a little like "promises" in E) That identifier can be used in making further requests, and it's automatically translated to instructions referencing the earlier request. If the identifier is used in an object local to the client, it is requested to be sent. This could be done explicitly in C, or via operator overloading in languages that support it. Perhaps it could even use an asynchronous mechanism like promises in E. -- Only you can prevent creeping featurism! --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
