Darren J Moffat wrote:
> Garrett D'Amore wrote:
>> Honestly, I've wished numerous times that I could use OpenSolaris for
>> certain projects. One of these we are stuck with Linux because:
>>
>> a) NetBSD's pthread implementation is busted
>> b) OpenSolaris is too hard to minimize adequately
>
> What have you tried and how did it fail ?
Well, to be honest, we didn't try very hard, mostly because it became
obvious that for the project we were looking at it was going to be an
enormous amount of work, with little chance of success. libc by itself
is almost too big at over 1MB. More on that in a bit. (There are other
projects that I would like to embark on using a minimal install, where
the constraints are not so tight.)
> What was the approach to you to doing the install ?
We understand not using suninstall. :-) We have our own installation
programs (which largely amount to the use of "tar") in the factory.
suninstall wasn't an issue.
> How did you choose what to keep and what to remove ?
We would have ditched most of userland. The problem was in figuring out
what to keep and what to toss.
> What is the goal installed on disk size ?
As small as possible. For this project we were targetting just a few
megabytes -- compressed, because we wanted to have a "consolidated
image" which could be updated over the network without taking forever.
We were using a CF adapter of 64MB, and almost the entire flash is
available for the OS once it is decompressed.
> What is the goal memory footprint ?
64MB total RAM, so we were looking at something less than that for OS
use. (Say we needed 16MB for application, which includes about 12MB for
graphics framebuffer space.)
>
> What can we do - in the appliances community even! - to resolve this ?
I doubt OpenSolaris would have ever been suitable for our project...
which is basically a reimplementation of a Sun Ray client on a "real"
operating system.
But there are lots of other projects with more generous constraints, but
which require much tighter constraints than the typical desktop or
server. I would seriously consider a target with 64MB flash, and as
_small_ as possible compressed image, along with run-time memory
constraints of 64MB or less (not including memory used for NFS, caching,
etc. ... i.e. just the core operating system should run reasonably in
64MB or less) to be useful.
There are still a lot of folks building embedded devices with 64MB.
(Actually, devices down to 8 or 4MB or common, but Solaris isn't
reasonable in those places. But think of an Au1550 MIPS device running
with 32 or 64MB RAM. A Solaris based thin-client or home gateway could
be interesting in this arena. Even more interesting is the idea of a
Niagra based NFS server running from compactflash.)
>
> The most important advice about building an OpenSolaris based
> appliance or embedded system I would give is to completely forget
> about using the install system that Solaris uses. Some of the other
> distros might have something better but ideally for an appliance the
> installer probably needs to have no questions asked at all and be as
> simple as unpacking a single file to the disk image (either tar, cpio,
> dd pick your poison) and probably being able to fetch that over
> tftp,https would be good.
That's obvious. We use a compressed tar (with some other "obfuscation")
for delivery. In order to make it reasonable for delivery over tftp
(which is what we use), it has to be reasonable in size. We targetted
(arbitrarily) a 5MB image size after compression. That's because we
anticipated hundreds of these devices from a single server, and we
wanted to minimize the impact of automatic firmware update (which we do
automatically, like a Sun Ray) upon our users.
-- Garrett
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
