Hello list,
I need to design a very small embedded system that must only control
one ethernet port and two serial lines and must fit in a very small flash
memory. So I thought about replacing the call to /etc/init by my application
program and removing all the file-system part of linux.
Is that doable ?
Is there a 'standard' way of doing that ?
The first problem I see is accessing my serial lines. How could I do that
without using open("/dev/ttySx"), which requires a file system ?
Is there a way to access devices that does not require a file-system ?
Thanks for reading this far
Philippe
> I need to design a very small embedded system that must only control
> one ethernet port and two serial lines and must fit in a very small flash
> memory. So I thought about replacing the call to /etc/init by my application
> program and removing all the file-system part of linux.
>
> Is that doable ?
>
> Is there a 'standard' way of doing that ?
>
> The first problem I see is accessing my serial lines. How could I do that
> without using open("/dev/ttySx"), which requires a file system ?
>
> Is there a way to access devices that does not require a file-system ?
You could put everything in initramfs (and embed it in the kernel).
--
Tomasz Chmielewski
http://wpkg.org
On Wed, Jan 14, 2009 at 09:46:48AM +0100, Tomasz Chmielewski wrote:
>> I need to design a very small embedded system that must only control
>> one ethernet port and two serial lines and must fit in a very small flash
>> memory. So I thought about replacing the call to /etc/init by my
>> application
>> program and removing all the file-system part of linux.
>> Is that doable ?
>> Is there a 'standard' way of doing that ?
>> The first problem I see is accessing my serial lines. How could I do that
>> without using open("/dev/ttySx"), which requires a file system ?
>> Is there a way to access devices that does not require a file-system ?
>
> You could put everything in initramfs (and embed it in the kernel).
Actually, I was thinking about reducing the footprint of my kernel by
removing all the fs-related system calls, so the problem is not where
the file-system is, but how to access (serial) devices without giving their
"/dev/..." name.
Thanks anyway
Philippe
> Is there a way to access devices that does not require a file-system ?
No: but you can run with just your own programs and bits needed loaded
off an initial ramdisk or a romfs image. A better place to ask and learn
is probably the "busybox" list as most people doing this stuff use
busybox for their tools
On Wed, Jan 14, 2009 at 10:52:24AM +0100, Xavier Bestel wrote:
>
> On Wed, 2009-01-14 at 10:34 +0100, Philippe De Muyter wrote:
> > On Wed, Jan 14, 2009 at 09:46:48AM +0100, Tomasz Chmielewski wrote:
> > >> I need to design a very small embedded system that must only control
> > >> one ethernet port and two serial lines and must fit in a very small flash
> > >> memory. So I thought about replacing the call to /etc/init by my
> > >> application
> > >> program and removing all the file-system part of linux.
> > >> Is that doable ?
> > >> Is there a 'standard' way of doing that ?
> > >> The first problem I see is accessing my serial lines. How could I do that
> > >> without using open("/dev/ttySx"), which requires a file system ?
> > >> Is there a way to access devices that does not require a file-system ?
> > >
> > > You could put everything in initramfs (and embed it in the kernel).
> >
> > Actually, I was thinking about reducing the footprint of my kernel by
> > removing all the fs-related system calls, so the problem is not where
> > the file-system is, but how to access (serial) devices without giving their
> > "/dev/..." name.
>
> You can still mount sysfs somewhere and access the device nodes from
> there.
Keeping thinking about it, I now think that my 'application program'
(basically a serial-to-ethernet converter) should be a kernel thread,
because of the small memory constraints.
The question is thus how to access the serial lines from a kernel thread.
Philippe
On Wed, 2009-01-14 at 10:34 +0100, Philippe De Muyter wrote:
> On Wed, Jan 14, 2009 at 09:46:48AM +0100, Tomasz Chmielewski wrote:
> >> I need to design a very small embedded system that must only control
> >> one ethernet port and two serial lines and must fit in a very small flash
> >> memory. So I thought about replacing the call to /etc/init by my
> >> application
> >> program and removing all the file-system part of linux.
> >> Is that doable ?
> >> Is there a 'standard' way of doing that ?
> >> The first problem I see is accessing my serial lines. How could I do that
> >> without using open("/dev/ttySx"), which requires a file system ?
> >> Is there a way to access devices that does not require a file-system ?
> >
> > You could put everything in initramfs (and embed it in the kernel).
>
> Actually, I was thinking about reducing the footprint of my kernel by
> removing all the fs-related system calls, so the problem is not where
> the file-system is, but how to access (serial) devices without giving their
> "/dev/..." name.
You can still mount sysfs somewhere and access the device nodes from
there.
Xav
On Wed, Jan 14, 2009 at 10:52, Xavier Bestel <[email protected]> wrote:
> On Wed, 2009-01-14 at 10:34 +0100, Philippe De Muyter wrote:
>> On Wed, Jan 14, 2009 at 09:46:48AM +0100, Tomasz Chmielewski wrote:
>> >> I need to design a very small embedded system that must only control
>> >> one ethernet port and two serial lines and must fit in a very small flash
>> >> memory. So I thought about replacing the call to /etc/init by my
>> >> application
>> >> program and removing all the file-system part of linux.
>> >> Is that doable ?
>> >> Is there a 'standard' way of doing that ?
>> >> The first problem I see is accessing my serial lines. How could I do that
>> >> without using open("/dev/ttySx"), which requires a file system ?
>> >> Is there a way to access devices that does not require a file-system ?
>> >
>> > You could put everything in initramfs (and embed it in the kernel).
>>
>> Actually, I was thinking about reducing the footprint of my kernel by
>> removing all the fs-related system calls, so the problem is not where
>> the file-system is, but how to access (serial) devices without giving their
>> "/dev/..." name.
>
> You can still mount sysfs somewhere and access the device nodes from
> there.
There are no device nodes in sysfs to talk to the device, only
attributes, which are mostly plain small text files. For some devices
there are a few writable and mappable files which can change the
device's state, but that's nothing like a device node.
Kay
On Wednesday 14 January 2009, Philippe De Muyter wrote:
> Actually, I was thinking about reducing the footprint of my kernel by
> removing all the fs-related system calls, so the problem is not where
> the file-system is, but how to access (serial) devices without giving their
> "/dev/..." name.
One thing that you can do is remove support for block devices in somewhat
recent kernels, which gets you most of the way. File systems themselves
are required for the majority of all system calls (anything that takes
a file descriptor) and for the boot process.
Arnd <><
On Wed, Jan 14, 2009 at 12:59:49PM +0100, Arnd Bergmann wrote:
> On Wednesday 14 January 2009, Philippe De Muyter wrote:
> > Actually, I was thinking about reducing the footprint of my kernel by
> > removing all the fs-related system calls, so the problem is not where
> > the file-system is, but how to access (serial) devices without giving their
> > "/dev/..." name.
>
> One thing that you can do is remove support for block devices in somewhat
> recent kernels, which gets you most of the way. File systems themselves
> are required for the majority of all system calls (anything that takes
> a file descriptor) and for the boot process.
file descriptor is actually an historical name, now too particular.
I would like to keep sockets and serial lines, for which the handle is a
"file descriptor", but not use any file. So, of course I need to keep
write(), read(), poll(), socket() etc, but not open(), link(), mknod() and
everything that walks a directory tree.
Philippe
Oh yes sorry, I mixed that with the dev entry in sysfs, which contains
the device major:minor in textual form (e.g. /sys/block/fd0/dev).
Confused memory ...
Xav
On Wed, 2009-01-14 at 11:34 +0100, Kay Sievers wrote:
> On Wed, Jan 14, 2009 at 10:52, Xavier Bestel <[email protected]> wrote:
> > On Wed, 2009-01-14 at 10:34 +0100, Philippe De Muyter wrote:
> >> On Wed, Jan 14, 2009 at 09:46:48AM +0100, Tomasz Chmielewski wrote:
> >> >> I need to design a very small embedded system that must only control
> >> >> one ethernet port and two serial lines and must fit in a very small flash
> >> >> memory. So I thought about replacing the call to /etc/init by my
> >> >> application
> >> >> program and removing all the file-system part of linux.
> >> >> Is that doable ?
> >> >> Is there a 'standard' way of doing that ?
> >> >> The first problem I see is accessing my serial lines. How could I do that
> >> >> without using open("/dev/ttySx"), which requires a file system ?
> >> >> Is there a way to access devices that does not require a file-system ?
> >> >
> >> > You could put everything in initramfs (and embed it in the kernel).
> >>
> >> Actually, I was thinking about reducing the footprint of my kernel by
> >> removing all the fs-related system calls, so the problem is not where
> >> the file-system is, but how to access (serial) devices without giving their
> >> "/dev/..." name.
> >
> > You can still mount sysfs somewhere and access the device nodes from
> > there.
>
> There are no device nodes in sysfs to talk to the device, only
> attributes, which are mostly plain small text files. For some devices
> there are a few writable and mappable files which can change the
> device's state, but that's nothing like a device node.
>
> Kay
>
Philippe De Muyter wrote:
> Actually, I was thinking about reducing the footprint of my kernel by
> removing all the fs-related system calls, so the problem is not where
> the file-system is, but how to access (serial) devices without giving their
> "/dev/..." name.
That's fighting the UNIX design, in "which everything is a file." You
can remove all of the disk-based filesystems, but if you try to remove
open, close, read or write there'll be almost nothing that you can
usefully do.
Philippe De Muyter wrote:
> Keeping thinking about it, I now think that my 'application program'
> (basically a serial-to-ethernet converter) should be a kernel thread,
> because of the small memory constraints.
>
> The question is thus how to access the serial lines from a kernel thread.
>
> Philippe
If your constraints are that severe, perhaps you should be investigating
other solutions. e.g. eCos?
Linux doesn't ALWAYS have to be the answer :-)
Rogan
On Thu, Jan 15, 2009 at 12:57:55AM +1030, David Newall wrote:
> Philippe De Muyter wrote:
> > Actually, I was thinking about reducing the footprint of my kernel by
> > removing all the fs-related system calls, so the problem is not where
> > the file-system is, but how to access (serial) devices without giving their
> > "/dev/..." name.
>
> That's fighting the UNIX design, in "which everything is a file." You
> can remove all of the disk-based filesystems, but if you try to remove
> open, close, read or write there'll be almost nothing that you can
> usefully do.
Of course, I need read, write and ioctl and socket and friends but I do not
need open, creat, link, rename etc.
Philippe
On Wed, Jan 14, 2009 at 04:27:55PM +0200, Rogan Dawes wrote:
> Philippe De Muyter wrote:
>
> > Keeping thinking about it, I now think that my 'application program'
> > (basically a serial-to-ethernet converter) should be a kernel thread,
> > because of the small memory constraints.
> >
> > The question is thus how to access the serial lines from a kernel thread.
> >
> > Philippe
>
> If your constraints are that severe, perhaps you should be investigating
> other solutions. e.g. eCos?
I like to reuse (and contribute to) the linux drivers and kernel.
> Linux doesn't ALWAYS have to be the answer :-)
No ? :)
Philippe
Philippe De Muyter wrote:
> On Wed, Jan 14, 2009 at 04:27:55PM +0200, Rogan Dawes wrote:
>> Philippe De Muyter wrote:
>>
>>> Keeping thinking about it, I now think that my 'application program'
>>> (basically a serial-to-ethernet converter) should be a kernel thread,
>>> because of the small memory constraints.
>>>
>>> The question is thus how to access the serial lines from a kernel thread.
>>>
>>> Philippe
>> If your constraints are that severe, perhaps you should be investigating
>> other solutions. e.g. eCos?
>
> I like to reuse (and contribute to) the linux drivers and kernel.
>
>> Linux doesn't ALWAYS have to be the answer :-)
>
> No ? :)
>
> Philippe
>
Ok, in that case, perhaps you should explain exactly what your
constraints are (target board, max memory/flash, etc), and maybe folks
will be able to provide more sensible answers.
Good luck!
Rogan
Philippe De Muyter wrote:
> On Thu, Jan 15, 2009 at 12:57:55AM +1030, David Newall wrote:
>
>> Philippe De Muyter wrote:
>>
>>> Actually, I was thinking about reducing the footprint of my kernel by
>>> removing all the fs-related system calls, so the problem is not where
>>> the file-system is, but how to access (serial) devices without giving their
>>> "/dev/..." name.
>>>
>> That's fighting the UNIX design, in "which everything is a file." You
>> can remove all of the disk-based filesystems, but if you try to remove
>> open, close, read or write there'll be almost nothing that you can
>> usefully do.
>>
>
> Of course, I need read, write and ioctl and socket and friends but I do not
> need open, creat, link, rename etc.
I think you do need open; how else will you open the serial port?
The best advice I can offer is: Don't think about kernel threads,
user-space is where you should be; and don't think about removing system
calls. If your application truly is so tight, linux might not be the
right tool for you.
Maybe the embedded linux list might be more in tune with what you're
thinking.
On Wed, Jan 14, 2009 at 04:57:09PM +0200, Rogan Dawes wrote:
> Philippe De Muyter wrote:
> > On Wed, Jan 14, 2009 at 04:27:55PM +0200, Rogan Dawes wrote:
> >> Philippe De Muyter wrote:
> >>
> >>> Keeping thinking about it, I now think that my 'application program'
> >>> (basically a serial-to-ethernet converter) should be a kernel thread,
> >>> because of the small memory constraints.
> >>>
> >>> The question is thus how to access the serial lines from a kernel thread.
> >>>
> >>> Philippe
> >> If your constraints are that severe, perhaps you should be investigating
> >> other solutions. e.g. eCos?
> >
> > I like to reuse (and contribute to) the linux drivers and kernel.
> >
> >> Linux doesn't ALWAYS have to be the answer :-)
> >
> > No ? :)
> >
> > Philippe
> >
>
> Ok, in that case, perhaps you should explain exactly what your
> constraints are (target board, max memory/flash, etc), and maybe folks
> will be able to provide more sensible answers.
if possible, mcf52236 (256k flash 32k sram in chip) :)
kernel+uapplication XIP in flash
they seems to push something called utasker
Philippe
Philippe De Muyter wrote:
> On Wed, Jan 14, 2009 at 04:57:09PM +0200, Rogan Dawes wrote:
>> Ok, in that case, perhaps you should explain exactly what your
>> constraints are (target board, max memory/flash, etc), and maybe folks
>> will be able to provide more sensible answers.
>
> if possible, mcf52236 (256k flash 32k sram in chip) :)
256kB flash? Good luck with that!
> kernel+uapplication XIP in flash
>
> they seems to push something called utasker
Maybe it is the best solution . . .
Rogan
>>>>> "Philippe" == Philippe De Muyter <[email protected]> writes:
Philippe> On Wed, Jan 14, 2009 at 09:46:48AM +0100, Tomasz Chmielewski wrote:
>>> I need to design a very small embedded system that must only control
>>> one ethernet port and two serial lines and must fit in a very small flash
>>> memory. So I thought about replacing the call to /etc/init by my
>>> application
>>> program and removing all the file-system part of linux.
>>> Is that doable ?
>>> Is there a 'standard' way of doing that ?
>>> The first problem I see is accessing my serial lines. How could I do that
>>> without using open("/dev/ttySx"), which requires a file system ?
>>> Is there a way to access devices that does not require a file-system ?
>>
>> You could put everything in initramfs (and embed it in the kernel).
Philippe> Actually, I was thinking about reducing the footprint of my
Philippe> kernel by removing all the fs-related system calls, so the
Philippe> problem is not where the file-system is, but how to access
Philippe> (serial) devices without giving their "/dev/..." name.
Does it have to be linux? I've been playing with Arduino boards
(http://www.adafruit.com) lately and they have ethernet modules,
serial libraries, etc. All on a small small chip. Well, the ethernet
is a daughter board, but they're still pretty small.
Depends on how general purpose you need to make this device and what
you're trying to accomplish. Maybe you need to give people a better
idea of what you're trying to do, instead of assuming you need Linux
and trying to shoe-horn it into a really tiny space.
Cheers,
John
* Alan Cox <[email protected]> wrote:
Hi,
> > Is there a way to access devices that does not require a file-system ?
>
> No: but you can run with just your own programs and bits needed loaded
> off an initial ramdisk or a romfs image.
Well, it (IMHO) depends on what you call a filesystem. If you're
talking about something that stores files (= byte streams with
some assigned name) on some medium, you *could* come around this
(in theory, no idea if it really makes sense): put everything you
need into one big static executable, let the bootloader load it
before the kernel is started (just like initrd ?) and hack up
the kernel to get that damn thing started.
BUT: it you're talking about the VFS stuff - it's a fundamental
building block of the OS, required in many many places (from
socket operations to kernel runtime config, ...) - if you *really*
want an OS w/o VFS, you better look at certain embedded-specific
OS'es ;-P
BTW: I'd really like to see much more things handled through the
filesystem (eg. networking API through some /net filesystem, like
on Plan9 ;-p) and let the dozens of syscalls, nelink socket, etc,
etc die out.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
On Wednesday 14 January 2009, Philippe De Muyter wrote:
> if possible, mcf52236 (256k flash 32k sram in chip) :)
>
> kernel+uapplication XIP in flash
>
> they seems to push something called utasker
In 256kb it will be hard to even support simple user space.
One solution might be to just use linux as a library and
implement your application code in the kernel, inside
of the . That lets you throw out all system calls and some
of the init code of the kernel (don't call rest_init).
At that stage, you have lost most of the advantages of
using Linux over some other kernel.
Arnd <><
* Kay Sievers <[email protected]> wrote:
> There are no device nodes in sysfs to talk to the device, only
> attributes, which are mostly plain small text files.
Actually, it would be really cool if all serial port operations
could be done via sysfs, so we don't need the device node
(including all its ioctl()) at all.
BTW: did I already mention that I don't like ioctl() ?
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------