Talk:Klibc

This article was nominated for deletion on 16 June 2007. The result of the discussion was no consensus.

This article is rated Stub-class on Wikipedia's content assessment scale.
It is of interest to the following WikiProjects:

Computing

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on the project's importance scale.
	This article has been automatically rated by a bot or other tool as Stub-class because it uses a stub template. Please ensure the assessment is correct before removing the `\|auto=` parameter.

category?

Why is this in the "C standard library" category? This article describes klibc as a suite of programs, not a library for C. It describes it as a "minimalistic" library; what's missing compared to the C standard library? If it's a "minimalistic" implementation, how can it claim to be a "standard" implementation? -- Mikeblas 01:48, 30 May 2007 (UTC)[reply]

I don't think there is a "C minimalist library" category. The category has things related to "C standard libraries" besides klibc. For instance, "Return-to-libc attack". Certainly someone looking for a small standard library might wish to take klibc into consideration (as well as uCLibc and dietlibc). Bpringlemeir 13:06, 25 June 2007 (UTC)[reply]

I wasn't asking for a "C minimalist library" category. People looking for something to consider shouldn't be using Wikipedia, as it isn't a guide or a directory. My question was about finding accurate content for this article. A C library includes C functions, not commands; so why did this article provide a list of commands? If a library claims to be "minimalistic", that's great -- how did it earn that title? Is it smaller in implementation size or scope? By how much? -- Mikeblas 19:47, 30 June 2007 (UTC)[reply]

Fair enough. However, there is an overlap between guides, directories and encyclopedias. For instance, the selection process requires a rational for why klibc exists. Unfortunately, the article currently doesn't provide this information and it is up to the reader to research it. The only information on klibc is from people related to the kernel development. Ie, there is a lot of stuff in linux/Documentation. For instance, filesystems/ramfs-rootfs-initramfs.txt, early-userspace/*, filesytstems/tmpfs, etc. The best might be this,

Future directions:

...

The move to early userspace is necessary because finding and mounting the real root device is complex. Root partitions can span multiple devices (raid or separate journal). They can be out on the network (requiring dhcp, setting a specific mac address, logging into a server, etc). They can live on removable media, with dynamically allocated major/minor numbers and persistent naming issues requiring a full udev implementation to sort out. They can be compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned, and so on.

This kind of complexity (which inevitably includes policy) is rightly handled in userspace. Both klibc and busybox/uClibc are working on simple initramfs packages to drop into a kernel build.

The klibc package has now been accepted into Andrew Morton's 2.6.17-mm tree. The kernel's current early boot code (partition detection, etc) will probably be migrated into a default initramfs, automatically created and used by the kernel build.

I don't know how to write anything and not be accused of WP:NPOV violations. Maybe I am just gun shy from all of the negative people on WP. Also, it appears that klibc development is rather stagnant compared to uCLibc, busybox and buildroot projects. I couldn't really say why klibc was developed; Ie, why was newlib, dietlib and/or uCLibc not sufficient. There are some arguments about portability, but it seems more NIH to me. I don't think klibc was moved to the kernel tree. Bpringlemeir 20:58, 30 June 2007 (UTC)[reply]

Sorry to hear about your struggles with NPOV. Meanwhile, I'm still trying to get some clear information into this article, as it is self-contradictory at the moment. A C Runtime Library implementation doesn't include commands; and one that does include commands certainly isn't "minimalist". -- Mikeblas 14:26, 11 August 2007 (UTC)[reply]

Perhaps the alternative has better nomenclature. An alternate suite is the UClibc library and the buildroot package building collection. The main motivation of klibc is to populate an initramfs systems. This cpio/gzipped archive gets packed with the kernel. The kernel expands the cpio/gzipped file into a ram disk. The file system then takes over and can connect network drives and other complex tasks that may give access to the real root file system. The pivot_root program is used swap the initramfs root with the desired root mount point.

Unlike UClibc, klibc has reduced the amount of the C library functionality. So all of the programs that need to be linked with a C library have to be modified. This is why the klibc distribution contains both a library and a suite of programs. A better name would have been kbootsystem or something. Within the klibc distribution, there is a klibc directory containing the klibc library. The other programs are not part of the library and could have been a collection of patches to get the programs to work with klibc.

The uCLibc/buildroot system will run somewhere in the order of 3MB. This compresses to about 1.5Mb. With the kernel, it is still too big to fit on a floppy. Maybe that is a laudable target, but klibc tries to be even lighter than UClibc Bpringlemeir 21:45, 11 August 2007 (UTC)[reply]

capitalizaiton

Is it "KLibc" or "klibc"? The article uses both. -- Mikeblas 14:23, 11 August 2007 (UTC)[reply]

-> "klibc" a quick grep in the latest src shows only lowercase, thus fixed in article.