| unixabg | apw: Please consider this patch for casper http://fyeox.com/downloads/casper.patch | 03:12 |
|---|---|---|
| unixabg | It takes advantage of the ability to mount multi-lower layers (I only tested with a couple) but it does work | 03:13 |
| unixabg | and I think is a good update to casper. I also tested a couple of installs, which the support of multiple .squashfs | 03:15 |
| unixabg | files does not appear to break normal installs. s/couple/couple of extra .squashfs files located along side | 03:16 |
| unixabg | the filesystem.squashfs inside casper dir. | 03:16 |
| === JanC is now known as Guest89629 | ||
| === JanC_ is now known as JanC | ||
| memguy | O just got a way with pagemaps file to figure out what parts of memory attributes are set for pages and memory regions like mlocks , ...and many other memory things. And i have a way to determine all file locks so the last thing is a way to get the info from /proc for process locks or code locks or thread locks , mutex, semphores, spinlocks ,..etc | 07:56 |
| memguy | I don't think it exists but i can definitely add a temp LKM to give me the extra task_struct substructure info for process locks, signal, syscalls, or any other thing i thing is missing . I think syscall and signal files are there though so maybe only locks | 07:58 |
| === Elimin8r is now known as Elimin8er | ||
| === maxb_ is now known as maxb | ||
| === cmagina is now known as cmagina_away | ||
| memguy | ok so initrd initramfs,...etc would be only need if the drivers are not compiled into the kernel. I.E initrd and other names for it is nothing more then a ramdisk that is initial mounted so that one can load the right LKM drivers to mount the real root file system that the /sbin/init is executed to kick off a usable OS. | 18:18 |
| memguy | But why does compiling in make the kernel bloaty ? | 18:18 |
| memguy | The other option is your using memory for a ramdisk and loading the drivers as LKM so how is that less bloaty | 18:19 |
| memguy | I get the purpose of a ramdisk like initrd , initramfs, squashfs (compressed version) ,..etc are useful if you want the OS not to uses any secondary storage but not for huge sizes increases | 18:20 |
| memguy | Also if one compiled the drivers needed like ext4 into the kernel all one would need i think would be to tell grub where the kernel images is and then the kernel would do the rest as a single self contained application | 18:22 |
| infinity | memguy: Not everyone has the same computer or the same filesystem, etc. | 19:48 |
| infinity | memguy: Compiling in *all* the modules bloats the kernel immensely. | 19:48 |
| infinity | memguy: For your own personal builds, it's indeed plausible to build a monolithic kernel without any loadable modules, and you won't need an initrd if you don't need userspace tools (lvm, mdadm, luks, etc) to find and mount root. | 19:50 |
| memguy | yes but if you know the file system the kernel is going to be on then compiling that one file system driver into the kernel not as a Module M would not increase the size all that much. I am just saying if you already " know the filesystem its going to uses" | 19:50 |
| infinity | memguy: Like I said, for your own personal non-distro builds, that's fine. Distro kernels can't make assumptions, so we opt for maximum flexibility with minimal footprint. | 19:51 |
| infinity | And it's not about what filesystem the kernel is on, grub handles that, it's about what filesystem root is. | 19:52 |
| infinity | And we don't tell people how they have to format root. | 19:52 |
| memguy | ok i get that but your assumption that LKM won't be available is wrong they will be after the file system is mounted and chroot or pivot root occurs | 19:52 |
| infinity | The kernel modules live on the root filesystem. You need modules to mount the root filesystem. That's the whole point of the initrd. | 19:52 |
| Martiini | is there anyone here who works for ubuntu/canonical | 19:53 |
| memguy | then /sbin/init and onward if one has modprobe, insmod will beable to load LKM you just need the file system driver stuff built in | 19:53 |
| infinity | memguy: You're talking in circles here. For *you*, that works. For people with zfs, xfs, lvm, raid, etc, etc, it doesn't. Not unless we build everything in. Nevermind all the SCSI controllers and the like we need to build in to even find the disks. | 19:54 |
| infinity | memguy: Trust me, we didn't decide to have an initrd just cause it's hip and cool. | 19:54 |
| memguy | And i get that for a distro you don't want to assume ext4 but if you already know that then you should beable to get rid of initrd , initramfs, squashfs , casper,,...etc | 19:54 |
| infinity | memguy: Even if we assume a filesystem and enforce that (which we won't), you're missing device drivers. | 19:55 |
| memguy | Ya so if your using that many layers up then i agree there would be alot of built in module that would bloat it i see now | 19:55 |
| memguy | zfs ,lvm,..etc | 19:56 |
| infinity | memguy: The bootloader loads the kernel and initrd using Very Slow BIOS/EFI/etc calls, then the kernel flips to protected mode and can't call back into that. We need real drivers for every SCSI/ATA/etc device you may have your root disk on. | 19:56 |
| memguy | well not ever just the one your machine uses but for a general distro i get you cann't make that assumption | 19:57 |
| infinity | memguy: Better way to look at this. Look at the size of your initramfs on disk. If we built literally everything into the kernel to find every root, that's how much bigger your kernel would be, and that memory would never be freed. | 19:57 |
| infinity | memguy: Anyhow, like I said, for specific people and usecases, an initrd isn't necessary. You're right. But no point bringing it up in a distro kernel channel, where we absolutely need one. | 19:58 |
| memguy | Ok there reason why i asked is that with grub i after i compile the kernel and give it the initrd or ramdisk path i get it kernel panicing cann't find initrd and the path is clearly correct | 19:59 |
| infinity | Martiini: Probably. The general rule of public channels is "don't ask to ask, just ask". That probably applies to what you're not asking. | 19:59 |
| infinity | memguy: I'd say the path clearly isn't correct, or it's not a valid ramdisk. | 20:00 |
| infinity | memguy: It's grub's job to load the initrd you ask for into RAM, then the kernel unpacks it and execs init from it, like it would any other root filesystem. | 20:01 |
| memguy | Maybe because i am using grub2 and i edit the config file directly like regular grub thats the issue i should rerun the grub programs | 20:01 |
| infinity | memguy: So, either it's broken, or you fed grub the wrong location. | 20:01 |
| memguy | to built the new menu item for the kernel | 20:01 |
| infinity | update-grub is generally how Ubuntu's grub2 likes to update itself. | 20:01 |
| memguy | I was pretty good with grub so maybe it was the grub2 changes that screwed things up. | 20:02 |
| Martiini | I've had this idea - makeing of device specific compiled kernels, similar to android kernels on phones - custom made made kernels for all laptops etc .. Is it possible | 20:02 |
| infinity | Martiini: It's not going to happen for the distro, no. | 20:02 |
| memguy | Also do you need a different initrd intramfs ,..etc for different kernel x86 or x64 or different arch's | 20:03 |
| infinity | Martiini: It's certainly "possible" to do yourself, but good luck QAing 200 kernels. | 20:03 |
| infinity | memguy: The initrd contains kernel modules matching your exact kernel, and userspace bits matching your root. Extrapolate your answer from there. | 20:03 |
| Martiini | what if every distro would compile/download for each laptop/device specific kernel | 20:03 |
| infinity | Martiini: Then we'd have no way to support the result. | 20:04 |
| memguy | so you need a unquie initrd or ramdisk for each different kernel compiled | 20:04 |
| infinity | Martiini: Not sure why you think this would be any better than a generic kernel with a bunch of driver modules. | 20:04 |
| infinity | memguy: Yes. | 20:05 |
| memguy | Does it matter if the arch is the same but the version is different for the kernel? | 20:05 |
| Martiini | I just noticed that phones run faster with custom built kernels | 20:05 |
| infinity | memguy: It has to be exactly the same (or, to be fair, ABI compatible, but usually you break ABI when mangling a kernel build) | 20:05 |
| infinity | Martiini: Apples and oranges. x86 laptops aren't ARM phones. | 20:06 |
| Martiini | yes | 20:06 |
| infinity | Martiini: And in the ARMv7 phone case, it's not that you *can* have a custom kernel, it's that you *must* have a custom kernel with the vendor's device-specific goop. | 20:07 |
| infinity | Martiini: A generic ARMv7 kernel that actually has all the right bits for 7 devices works great on those 7 devices and doesn't magically get faster if you drop support for 6 of them. | 20:07 |
| memguy | ok that is probably my issue and the fact i edit the configuration file that said don't edit this config file uses some grub2 utitlty program | 20:07 |
| infinity | (Gets a bit smaller, but not faster) | 20:07 |
| infinity | Martiini: Unless the way you're measuring "speed" is boot times. Then, yes, a very generic kernel can take a second or three more to boot as it probes for hardware you don't have, etc. But once it's running, it's just a tiny bit of wasted memory, and otherwise a non-issue. | 20:08 |
| memguy | but the path was correct probably not the correct path to the correct initrd maybe. Or the config if when editing but some char in that shouldn;t have been added | 20:09 |
| memguy | thanks | 20:09 |
| infinity | And given that, before Google started doing monthly updates, my phone had an uptime of 9 months (and how it's one month at a time), boot time seems irrelevant. | 20:09 |
| Martiini | ubuntu and archbang are fastest distros, but I guess it's not because of kernel | 20:24 |
| memguy | If i create another LKM since i am at the kernel level can i just read any memory location like if i open /dev/mem will have have no access restrictions like i do in userspace programs with open /dev/mem | 22:08 |
| memguy | Or am i still going to get page fault or other errors if the page that i am reading isn't mapped | 22:08 |
| memguy | I know i am not making sense but what i mean to figure out is how /dev/mem is allowing one to read physical memory without virtual address | 22:10 |
| memguy | I guess i just want know is how /dev/mem read physical memory because everything to a program is virtual memory even at the kernel level once page tables/paging is setup for it | 22:11 |
| memguy | does the first bytes at offset zero of /dev/mem corrospond to the physical memory 0x0000000 onward... or does it corrospond to the first page mapped in the page table | 22:12 |
| memguy | not necessarily placed at physical address 0x0000000. reading from it in user space seems from seeing bios info and grub info that its reading true physical but i just don't understand how this /dev/mem is doing this what is the driver or LKM for it that would shed light on it? | 22:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!