Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Extending the Linux Kernel with Built-In Kernel Headers

linuxjournal.com

Post reply on HN
Print view View original

21–30 of 62 posts

Re: Extending the Linux Kernel with Built-In Kernel Headers

#21

Post by kyberias »

stefan_ wrote: post #9
derefr wrote: post #5

Earlier quoted context omitted.

If it’s anything like GPU shaders, it’s because the bytecode format itself is Turing-complete and not-so-sandboxed, and the actual security/fault-tolerance comes from a static analysis pass done during compilation that ensures the source code being compiled isn’t doing anything crazy. If you were able to load bytecode directly, you’d skip this verification step. (I’ve always thought VM runtimes should have signing ke…

eBPF is specifically not Turing-complete because you can not prove any property of Turing-complete language code.

Of course one can make proofs of programs written in Turing complete languages.

Re: Extending the Linux Kernel with Built-In Kernel Headers

#22

Post by colechristensen »

sp332 wrote: post #14
stefan_ wrote: post #9

Earlier quoted context omitted.

eBPF is specifically not Turing-complete because you can not prove any property of Turing-complete language code.

eBPF is not Turing-complete, but static analysis can absolutely prove things about individual programs in Turing-complete languages.

You can prove some code in Turing complete languages.

You can construct non-turing-complete languages which all code can be proven, and that is the point the parent is making.

Re: Extending the Linux Kernel with Built-In Kernel Headers

#24

Post by d33 »

kumbel wrote: post #2

> embed the kernel headers within the kernel image itself and make it available through the sysfs virtual filesystem (usually mounted at /sys) as a compressed archive file (/sys/kernel/kheaders.tar.xz) eeww

Why tarred and compressed though? If it wasn't, one could point a compiler directly at it.

Re: Extending the Linux Kernel with Built-In Kernel Headers

#25

Post by WhatIsDukkha »

d33 wrote: post #24
kumbel wrote: post #2

> embed the kernel headers within the kernel image itself and make it available through the sysfs virtual filesystem (usually mounted at /sys) as a compressed archive file (/sys/kernel/kheaders.tar.xz) eeww

Why tarred and compressed though? If it wasn't, one could point a compiler directly at it.

It goes into that, at length, in the article.

Re: Extending the Linux Kernel with Built-In Kernel Headers

#26

Post by AnIdiotOnTheNet »

MBCook wrote: post #13
forgottenpass wrote: post #12

Earlier quoted context omitted.

File this one under: kludges to get around openly user-hostile userland.

How so? Seems like an elegant enough solution to ensure you always have the right headers to build modules against the currently running kernel.

An elegant solution would be not having that problem in the first place.

Re: Extending the Linux Kernel with Built-In Kernel Headers

#27

Post by forgottenpass »

MBCook wrote: post #13
forgottenpass wrote: post #12

Earlier quoted context omitted.

File this one under: kludges to get around openly user-hostile userland.

How so? Seems like an elegant enough solution to ensure you always have the right headers to build modules against the currently running kernel.

Isn't kernel header availability a solved problem on any linux system that isn't busy pretending not to be built on linux?

Re: Extending the Linux Kernel with Built-In Kernel Headers

#28

Post by dang »

kumbel wrote: post #2

> embed the kernel headers within the kernel image itself and make it available through the sysfs virtual filesystem (usually mounted at /sys) as a compressed archive file (/sys/kernel/kheaders.tar.xz) eeww

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

Re: Extending the Linux Kernel with Built-In Kernel Headers

#29

Post by java-man »

colechristensen wrote: post #20
TheSoftwareGuy wrote: post #6

Earlier quoted context omitted.

It irks you because storing source code directly in the final binary is bonkers, but unfortuantely it is the only way to reveal all the complexity that can be exposed in a C header file. This isn't really just a C problem though. Even rust has a similar problem for propagating macros. The reason for this limitation is really that making an ABI for metaprograms (macros) is exceedingly difficult

Are there other languages that provide interfaces as cleanly as exposing C header files?

java interfaces.

I think the concept of coding to an interface (or an API specification) goes beyond what java did. In my professional life, I see people constantly downplaying and ignoring importance of a formal and stable API specification, just to suffer consequences later.

Re: Extending the Linux Kernel with Built-In Kernel Headers

#30

Post by colechristensen »

java-man wrote: post #29
colechristensen wrote: post #20

Earlier quoted context omitted.

Are there other languages that provide interfaces as cleanly as exposing C header files?

java interfaces. I think the concept of coding to an interface (or an API specification) goes beyond what java did. In my professional life, I see people constantly downplaying and ignoring importance of a formal and stable API specification, just to suffer consequences later.

If you just give me a .jar do I get those interfaces in a consumable form?

Said differently, can I download your .jar and write my own code to interface with it while on a desert island without any other resources?

Post reply on HN