| i915 | well the one i am using is using i915 for it kernel driver | 00:34 |
|---|---|---|
| i915 | so ya my special case it is | 00:35 |
| i915 | also my cases if probably no ware near as general as others have it | 00:36 |
| i915 | weird question when compiling a module the make file uses path /lib/modules/$(shell uname -r)/build which points to /usr/src/linux-headers-3.13.0-32/ looking to the Makefile you see lines like this obj-$(CONFIG_VGA_ARB) += vgaarb.o | 05:54 |
| i915 | obj-$(CONFIG_VGA_SWITCHEROO) += vga_switcheroo.o | 05:54 |
| i915 | I get what those make files are doing just including object files.... but where are these object files cann't find them anywhere so i am thinking they are zipped up in .a file or something | 05:55 |
| i915 | The kernel headers are not worth anything without the object files to link against... i do see alot of .ko files under the /lib/module/... but those are for the already built modules that can be insmod | 05:57 |
| === _ruben_ is now known as _ruben | ||
| mjg59 | i915: The .o files aren't shipped, because they're just intermediates between the .c and the .ko files | 06:02 |
| mjg59 | The headers give you the information you need to build modules from source | 06:03 |
| i915 | so why do the Makefiles have them in there or is that just left behind makefiles for the kernel itselfs code | 06:03 |
| i915 | Yes but the headers need to be associated with some type of kernel level library to build the modules that the header file uses? | 06:04 |
| mjg59 | Those are the makefiles from the kernel, yes | 06:07 |
| i915 | or another words what are these o files for. Because if the modules are just using the .ko files that see and the top level makefiles for target modules searches the .ko file directory then what was the .o files | 06:07 |
| mjg59 | There is no kernel level library | 06:07 |
| mjg59 | The .o files are generated from building the .c files. A single .ko may include several .o files. | 06:08 |
| mjg59 | They're just an intermediate during the build process | 06:08 |
| i915 | yes but for building just modules you could remove all those makefiles with .o and you should still beable to build your LKM | 06:09 |
| mjg59 | Sure, but ensuring that you remove those makefiles while not removing any that are required for the build process isn't really worth it | 06:09 |
| i915 | LKM from what i am gathering is just using the .ko files in the /lib/modules/3.13.0-32-generic/kernel/ subdirectories | 06:12 |
| mjg59 | Yes | 06:12 |
| i915 | well then one could archive .ko into one big allmodverion3.6.2.a then take your module header files and integrate it with user land functions i would imagine as well | 06:16 |
| mjg59 | No | 06:19 |
| i915 | unless the insertion insmod the output would fail or the structure of the LKM | 06:19 |
| mjg59 | Kernel code can't be executed in useland | 06:19 |
| mjg59 | It calls into functions that only exist in the kernel itself | 06:20 |
| mjg59 | And which can't be reimplemented in userspace | 06:20 |
| i915 | yes so when insmod tries to install the LKM even if it was to compile with user land header/library functions it would fail to install into the kernel level | 06:20 |
| i915 | because the user land libraries wouldn't work with kernel LKM | 06:21 |
| i915 | i am guessing thats the reason but i see no reason why a LKM cann't load a .so or a kernel level program call a user land library is there no load library that it can uses | 06:22 |
| i915 | Maybe it has to do with the way the LKM and its resources are loaded into memory that it cann't access user land libraries but to me it seems the kernel should have a method to call any function ,process, or program in memory... hell it can get a task or runqueue to access any program resources | 06:24 |
| i915 | So i am still left wondering what the real reason is why LKM or any kernel level program cann't get access or uses userland libraries or functions... in my eyes the kernel has complete control of memory and thus all it needs to do is locate the function in it... it also has complete control of the process so there you go you should beable to call upon anything in memory | 06:26 |
| i915 | Maybe because the userland users a loader program for the .so and so since its lower then the loader program it would need to go thru the loader first to dynamically load the userland libraries thats my only guess | 06:28 |
| i915 | But if the libraries where user libraries where specifically loaded for the LKM start up then you should also thru LKM or kernel functions beable to access the loaded library in memory by passing the loader | 06:32 |
| i915 | bypassing | 06:32 |
| i915 | and thus being able to call upon userland libraries from kernel mode | 06:33 |
| i915 | Of course the only problem would be the mapping of the .so file functions to proper address maybe this part would actually take a page allocated , many other things that essentially would be just creating a loader at the kernel level for user land libraries | 06:34 |
| i915 | Also the .got .plt ,...etc parts of the .elf for userland would have to be workable so you would need to somehow port a ld.so or some mechanism for that... | 06:36 |
| i915 | this is probably the issue to | 06:36 |
| i915 | maybe like the __jump_table section cann't be easilly converted to the got plt | 06:44 |
| === cpaelzer is now known as cpaelzer_away | ||
| === alvesadrian is now known as adrian | ||
| === cpaelzer_away is now known as cpaelzer | ||
| === cpaelzer is now known as cpaelzer_away | ||
| === cpaelzer_away is now known as cpaelzer | ||
| i915 | curious i was think again about LKM and if one statically compiled in user library function to it why would this not work the user land functions would be self contained in the LKM no dependences on .so | 14:38 |
| apw | if the module includes all of the code no reason any not, but most libraries assume they are running on top of the standard C library and expect to link to those kinds of things | 15:24 |
| apw | so most userpsace libraries would never find their deps | 15:24 |
| apw | not that it is clear why you would want to include all this userspace in a kernel module in the first place | 15:25 |
| ogra_ | modprobe gnome | 15:38 |
| ogra_ | ;) | 15:38 |
| JanC | well, there used to be a kernel module that implemented a http server because supposedly it was slightly faster than userspace http servers | 16:34 |
| JanC | it was also incredibly bad for security ;) | 16:35 |
| ogra_ | who cares about security anyways .. thats so last century ... | 16:36 |
| i915 | curious i see alot of kworker/u8:1 based stuff in ps -A are these workqueues created by the kernel | 19:52 |
| i915 | or are they tasklets created by the kernel I would imagine tasklets and softirq won't show up in ps -A on workqueues because workqueues are truely the pthreads version of the kernel i imagine | 19:58 |
| apw | kworker are the kernel contexts for work queuesyes | 20:00 |
| i915 | kthreadd , ksoftirqd, kworker ,khelper kind wondering what the difference in purpose of these and where these all created by workqueues | 20:06 |
| arges | https://github.com/0xAX/linux-insides/blob/master/interrupts/interrupts-9.md has some good info about these topics | 20:07 |
| i915 | ksoftirqd looks like it is a queue of interrupts when the interrupts come in to fast to process . But is there a way other then workerqueues to create a kernel process or is workqueues / tasks they way kernel threads are made in general | 20:09 |
| i915 | No forget it apparently i am wrong kthread functions with task_struct is the equivalent of pthreads .When would one uses workqueues over kthreads then ? | 20:13 |
| i915 | ok well i get a way to filter out kernel threads and user threads ps -fHuroot | awk '$3!=2' or ps -fHuroot | awk '$3==2' so i can distinguish between user and kernel threads provided the pid didn't change for your linux you can to or do it by the symlink -->exe in proc dev. Of course now my question is determining what the purpose of these different kernel process are . Next step is /proc/pid for them but not sure yet if it wil | 20:23 |
| i915 | l give me a way to figure out what they are meant for | 20:23 |
| i915 | Hum i am wondering if LKM are part of the kthreads process it looks like some are there but the names are different maybe they are contained with in the kernel threads trying to link the distinction of kthreads with LKM's | 20:30 |
| i915 | so its like kthreadd spawns all kernel threads i.e kworker threads but there is additional ones i still have to look into later tonight to get them all down would be nice to know where the LKM's leave in which on of these kernel threads/process if any. | 20:36 |
| i915 | because the insmod insertion into the kernel so i thought it would be a process/thread but maybe its just a fixed static code block that is hooked with irq hander routines to call the module functions. Or maybe the modules are normally just to set up irq for a callback handler that does the device driving not fully sure of all this yet | 20:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!