ken, I don't plan to stop the rom - only sample the 2.6 kernel to consider whether it is stable enough for distribution and use, and porting features.
ok, that's good to know.
It's understandable that you're busy and all. That being the case, I was wondering if you would consider a few thoughts ...
The guylhem rom is an ambitious but doable project, certainly something that a number of us want to see completed. The distribution however, has many aspects to it, many pieces, many parts that need to fit together.
That being the case, perhaps it would be useful to break them up into smaller bite sized portions?
At the very least, it would help in the troubleshooting process, to see if there is a piece that's inadvertantly affecting other parts? You've already gone far ahead of many of us, and there's little we can do to help figure out what's going on.
Your forums gives hints as to the directions you've taken, but I fear, not enough for someone like myself to get enough of a big picture.
Perhaps starting with something like:
1) tetsu's kernel (for the 6K it's up to 16a). That would provide people with ?. That also may possibly have other inclusions of things you want to do. That could be a starting point. He has for example, included bluetooth. Of course if you feel that using his kernel would have a number of disadvantages (which you'd know and I'd have no clue on), then of course, this would be a bad idea.
2) meanie's patches for usb perhaps?
3) a fast SDL - this is what attracted people to your rom in the first place - the idea that they could add a touch of speed to the 6K.
4) ability to have more than just 25%, 50%, 75% brightness
That being said, I have the feeling that you can already see how each thing would fit together, from just the kernel patches to the full blown guylhem distribution?
At least this way you could take more time to figure out where things are breaking?
There are specific things I want to improve: speed, hackability, compatibility - triple binds mutually exclusive - comes what may :-)
I have no disagreements there. Merely concerned that it may lose its momentum.
Actually I'm very interested in the suspend/resume time and the boottime. I want it to be blazing fast.
boot time is nice, but once it's booted, it's a not a biggie. suspect/resume, yes, I can see that. I suspect that's a long term goal though.
To do this, I did cut the kernel messages, and I'll certainly cut the logo. dmesg is still there- messages are just logged to ttyS0 instead of the console by default. I enabled sysv status report (ex: Checking filesystem [OK]) OTOH because it was important to find which part was hanging when a problem occured, even if it display stuff and therefore may add some delay. I am also adding a pretty issue screen, because of the hackability.
This part can be what I mentioned above. Tiny pieces that provide functionality, little modules that allow you to hack a part of the system, guaranteed to work.
suitable to handhelds. It could be based on something much more efficent and modern like
heh ... it's all good. The downside of course is your time gets spread further apart!
systems on microdrives or 40 Gb usb storage. adf - maybe your pdaxrom system (saw your instructions on the 6000 forum) could be included? All it needs is to work with guylhem rom.
I'm willing to help in any way I can. To that extent, I've been working on a page:
https://www.oesf.org/index.php?title=Applic...6000L/Sharp_ROMThis is geared of course to what we discussed, being that compatibility to the Sharp ROM is important. I'm also afraid that adding in gcc3 might break things, but you'd know better than myself whether it would or not.
Let me know how I can help.
btw, the article here:
http://www.externe.net/zaurus/modules.php?...order=0&thold=0that talks about a website is now located here:
http://home.mchsi.com/~cmisip/zaurus.htm
