Organizing your source code

[justin]

I'm looking for a better way to organize my code. In particular, what is the best way to organize additions to newlib? For example, in order to port cooler things I have had to implement things like termios and dirent. Now I have subdirectories parallel to my 'kernel' subdirectory labeled "syscalls", "termios", and "dirent" which contain code that I have added to my libc. I can foresee this becoming unwieldy. I know many of you have ported things like termios and such and I'm wondering:

1. Where is a good place to put this code?

2. How do you manage things like headers that are used both in the kernel and in user space? For example, things like "struct termios" need to be available to both the kernel and the user. How do you manage this in a way that you don't write the same code twice?

Thanks for your ideas.

[Gigasoft]

I use the same header for both kernel and user mode code. Others might have a common header file that is included by both header files. Or, you could use conditional compilation to leave out things that are not available in user mode when compiling an user mode program.

I prefer not having a lot of small files in various directories. When things actually become unwieldy, it's usually easy to see how things should be split up. I'd probably put everything related to the standard C library in one or two big files.

[bluemoon]

I dont care to invent a new schema so I stick to unix style (with little customizations):

general header usable for kernel, ddk and application: /usr/include/
kernel private header: $(KERNEL_PATH)/ and $(KERNEL_PATH)/arch/$(ARCH)
header specific for drivers development: $(KERNEL_PATH)/ddk/
application private header: anything legal

And if there are in fact two different entities for kernel and application, I would call them termios and k_termios to avoid confusing compiler and programmer.

[Combuster]

I prefer not having a lot of small files in various directories. When things actually become unwieldy, it's usually easy to see how things should be split up. I'd probably put everything related to the standard C library in one or two big files.

I don't want to have one or two big files, because their total size would be a huge unnavigable mess:

(...)/mos/libc $ find -iname '*.c' | xargs cat | wc -l
13120

And that's only worth half an libc implementation.

Besides, if you do static linking, binary bits are included from an archive on a per-file basis. Which means that all the libc functions you do not use in that app will end up being included in the file size.

as for additions, I only use one separate folder for the host-specific glue per included library - that makes it easy to isolate from the original library code.