unixabgapw: Please consider this patch for casper http://fyeox.com/downloads/casper.patch03:12
unixabgIt takes advantage of the ability to mount multi-lower layers (I only tested with a couple) but it does work03:13
unixabgand I think is a good update to casper. I also tested a couple of installs, which the support of multiple .squashfs03:15
unixabgfiles does not appear to break normal installs. s/couple/couple of extra .squashfs files located along side 03:16
unixabgthe filesystem.squashfs inside casper dir.03:16
=== JanC is now known as Guest89629
=== JanC_ is now known as JanC
memguyO 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 ,..etc07:56
memguyI 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 locks07:58
=== Elimin8r is now known as Elimin8er
=== maxb_ is now known as maxb
=== cmagina is now known as cmagina_away
memguyok 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
memguyBut why does compiling in make the kernel bloaty ?18:18
memguyThe other option is your using memory for a ramdisk and loading the drivers as LKM so how is that less bloaty18:19
memguyI 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 increases18:20
memguyAlso 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
infinitymemguy: Not everyone has the same computer or the same filesystem, etc.19:48
infinitymemguy: Compiling in *all* the modules bloats the kernel immensely.19:48
infinitymemguy: 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
memguyyes 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
infinitymemguy: 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
infinityAnd it's not about what filesystem the kernel is on, grub handles that, it's about what filesystem root is.19:52
infinityAnd we don't tell people how they have to format root.19:52
memguyok 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
infinityThe 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
Martiiniis there anyone here who works for ubuntu/canonical19:53
memguythen /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
infinitymemguy: 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
infinitymemguy: Trust me, we didn't decide to have an initrd just cause it's hip and cool.19:54
memguyAnd 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,,...etc19:54
infinitymemguy: Even if we assume a filesystem and enforce that (which we won't), you're missing device drivers.19:55
memguyYa 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 now19:55
memguyzfs ,lvm,..etc19:56
infinitymemguy: 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
memguywell not ever just the one your machine uses but for a general distro i get you cann't make that assumption19:57
infinitymemguy: 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
infinitymemguy: 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
memguyOk 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 correct19:59
infinityMartiini: 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
infinitymemguy: I'd say the path clearly isn't correct, or it's not a valid ramdisk.20:00
infinitymemguy: 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
memguyMaybe because i am using grub2 and i edit the config file directly like regular grub thats the issue i should rerun the grub programs20:01
infinitymemguy: So, either it's broken, or you fed grub the wrong location.20:01
memguyto built the new menu item for the kernel20:01
infinityupdate-grub is generally how Ubuntu's grub2 likes to update itself.20:01
memguyI was pretty good with grub so maybe it was the grub2 changes that screwed things up.20:02
MartiiniI'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 possible20:02
infinityMartiini: It's not going to happen for the distro, no.20:02
memguyAlso do you need a different initrd intramfs ,..etc for different kernel x86 or x64 or different arch's20:03
infinityMartiini: It's certainly "possible" to do yourself, but good luck QAing 200 kernels.20:03
infinitymemguy: The initrd contains kernel modules matching your exact kernel, and userspace bits matching your root.  Extrapolate your answer from there.20:03
Martiiniwhat if every distro would compile/download for each laptop/device specific kernel 20:03
infinityMartiini: Then we'd have no way to support the result.20:04
memguyso you need a unquie initrd or ramdisk for each different kernel compiled 20:04
infinityMartiini: Not sure why you think this would be any better than a generic kernel with a bunch of driver modules.20:04
infinitymemguy: Yes.20:05
memguyDoes it matter if the arch is the same but the version is different for the kernel?20:05
MartiiniI just noticed that phones run faster with custom built kernels20:05
infinitymemguy: 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
infinityMartiini: Apples and oranges.  x86 laptops aren't ARM phones.20:06
infinityMartiini: 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
infinityMartiini: 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
memguyok 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 program20:07
infinity(Gets a bit smaller, but not faster)20:07
infinityMartiini: 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
memguybut 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 added20:09
infinityAnd 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
Martiiniubuntu and archbang are fastest distros, but I guess it's not because of kernel 20:24
memguyIf 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/mem22:08
memguyOr am i still going to get page fault or other errors if the page that i am reading isn't mapped 22:08
memguyI 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 address22:10
memguyI 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 it22:11
memguydoes 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
memguynot 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!