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

Two Objects Not Namespaced by the Linux Kernel (2017)

blog.jessfraz.com

Post reply on HN
Print view View original

31–40 of 59 posts

Re: Two Objects Not Namespaced by the Linux Kernel (2017)

#31

Post by AceJohnny2 »

zapita wrote: post #20
haberman wrote: post #12

> The current set of namespaces in the kernel are: mount, pid, uts, ipc, net, user, and cgroup. [...] [Time is] not namespaced. [...] The kernel keyring is another item not namespaced. I've always argued that "everything is a file" is an exaggeration. These moments make the extent of that exaggeration clear. If everything truly was a file, the only thing you would need to namespace is the filesystem. But in reality t…

You are 100% correct. “Everything is a file” was more of an early design insight, which was gradually abandoned as new features were added. There is a movement of “Unix purists” who lament this deviation from founding principles, and advocate for a return to them. The most notable example is Plan 9. In Plan 9, everything actually is a file. And exactly as you said, all resources are namespaced via the filesystem. It’…

I also liked QNX, when I worked with it.

You really did access devices through the /dev/ system, and device-drivers were userspace programs that created files in /dev/.

If your driver crashed, you could kill the userspace driver (which deleted the file under /dev) and restart it (assuming hardware blah blah blah).

Re: Two Objects Not Namespaced by the Linux Kernel (2017)

#32

Post by tadfisher »

temac wrote: post #25
zapita wrote: post #20

Earlier quoted context omitted.

You are 100% correct. “Everything is a file” was more of an early design insight, which was gradually abandoned as new features were added. There is a movement of “Unix purists” who lament this deviation from founding principles, and advocate for a return to them. The most notable example is Plan 9. In Plan 9, everything actually is a file. And exactly as you said, all resources are namespaced via the filesystem. It’…

hm is NT a purer Unix than Unix then? After all, it has all its object in a filesystem-like tree...

In Windows NT, everything is an object. This is derived from VMS, which is essentially NT's predecessor (a principal designer of both being David Cutler of Digital Research and later Microsoft).

Re: Two Objects Not Namespaced by the Linux Kernel (2017)

#33

Post by sytelus »

haberman wrote: post #12

> The current set of namespaces in the kernel are: mount, pid, uts, ipc, net, user, and cgroup. [...] [Time is] not namespaced. [...] The kernel keyring is another item not namespaced. I've always argued that "everything is a file" is an exaggeration. These moments make the extent of that exaggeration clear. If everything truly was a file, the only thing you would need to namespace is the filesystem. But in reality t…

The abstraction is not really file but stream of bytes. It turns of any object with stream of bytes will need similar set of operations: open, create, read, write, close, seek etc. This is fairly generic and powerful abstraction.

Re: Two Objects Not Namespaced by the Linux Kernel (2017)

#34

Post by jackfraser »

tadfisher wrote: post #32
temac wrote: post #25

Earlier quoted context omitted.

hm is NT a purer Unix than Unix then? After all, it has all its object in a filesystem-like tree...

In Windows NT, everything is an object. This is derived from VMS, which is essentially NT's predecessor (a principal designer of both being David Cutler of Digital Research and later Microsoft).

The problem I always had with this was that Windows has this whole layer of objects and what might even be elegance in places all hidden under the hood, and unless you're a C++ hacker you can't actually work with most of it. CMD and the GUI tools never exposed half of it to you; Powershell helps, but it's all still very hidden and hard to get to.

In comparison, Unix provides all the tools needed to take it apart and put it back together again. When you do need to interact with some syscall interface, there's almost always a complete CLI around it. It really makes it much easier to get into the nooks and crannies, inconsistencies aside.

Re: Two Objects Not Namespaced by the Linux Kernel (2017)

#35

Post by simcop2387 »

lalaithion wrote: post #2

Why is this the case? No one has bothered to do it? It would break backwards compatibility? Linus thinks it's a bad idea?

The time namespace is being worked on, it's a very difficult problem because of how pervasive time is in the kernel.

Here's a recent in depth LWN article about the topic. https://lwn.net/Articles/766089/

They keychain stuff I haven't heard about any work being done but I don't know any reason it shouldn't be doable.

Re: Two Objects Not Namespaced by the Linux Kernel (2017)

#36

Post by atombender »

jackfraser wrote: post #34
tadfisher wrote: post #32

Earlier quoted context omitted.

In Windows NT, everything is an object. This is derived from VMS, which is essentially NT's predecessor (a principal designer of both being David Cutler of Digital Research and later Microsoft).

The problem I always had with this was that Windows has this whole layer of objects and what might even be elegance in places all hidden under the hood, and unless you're a C++ hacker you can't actually work with most of it. CMD and the GUI tools never exposed half of it to you; Powershell helps, but it's all still very hidden and hard to get to. In comparison, Unix provides all the tools needed to take it apart and…

He's talking about the kernel. The Windows NT kernel and the Windows APIs use handles to represent kernel/API objects, and every handle has things like security associated with it.

For example, CreateProcess() gives you back a HANDLE value representing the process, and you can close it with CloseHandle(). Everything is a HANDLE: Files, pipes, threads, etc. A notable exception is sockets, which for historical reasons use an API modeled on BSD sockets.

The object stuff you're talking about is presumably COM, which is different. COM is great, but has nothing to do with the kernel.

Re: Two Objects Not Namespaced by the Linux Kernel (2017)

#37

Post by fulafel »

haberman wrote: post #12

> The current set of namespaces in the kernel are: mount, pid, uts, ipc, net, user, and cgroup. [...] [Time is] not namespaced. [...] The kernel keyring is another item not namespaced. I've always argued that "everything is a file" is an exaggeration. These moments make the extent of that exaggeration clear. If everything truly was a file, the only thing you would need to namespace is the filesystem. But in reality t…

Yeah, this was one of the headline changes in Plan 9 (the second OS made by the Fathers of Unix).

Re: Two Objects Not Namespaced by the Linux Kernel (2017)

#38

Post by cyphar »

DonHopkins wrote: post #28
wmf wrote: post #3

Since this was written a time namespace was proposed: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Ti...

This proposal implements clock offsets, but does it support continuous time scaling? One clock-handy use case would be to run your programs really slow or fast (or backwards!), for testing purposes. Kaleida Lab's ScriptX (a multimedia programing language kinda like Dylan with classes) had built-in support for hierarchal clocks within the container (in the sense of "window" not "vm") hierarchy. The same way every wind…

> This proposal implements clock offsets, but does it support continuous time scaling?

No. The main reason why is because it's very difficult to do with the current time-keeping machinery within the kernel. Some people also want the ability to freeze the current time, which is also similarly difficult -- and in some cases harder because then what should CLOCK_MONATONIC give you? There's also the fact that there's currently no interface to set the "clock speed" do any of these things.

Making time go backwards I think would simply be impossible, due to how many things in the kernel that interact with time probably make the (reasonable) assumption that time goes forwards. Also CLOCK_MONATONIC would do the exact opposite in such circumstances.

Re: Two Objects Not Namespaced by the Linux Kernel (2017)

#39

Post by cyphar »

derefr wrote: post #7

I wonder whether namespacing time would also result in those namespaces being able to have separate "clocks" (time backends? time schedulers?) that progress at different rates, or for different reasons. Being able to put a process into a time namespace with a deterministic "clock" would obviate a large benefit of http://www.zerovm.org/ . Also, having "clock slew" be a matter of perspective—with processes that can han…

There is a time namespace proposal[1], but currently the answer to this question is no. The reason is that timekeeping is incredibly complicated within the kernel (for instance -- when userspace gets the current time, it's read from a vDSO page that the kernel injects into every process and thus is updated by the kernel asynchronously). Adding different clock speeds is already non-trivial, let alone switching out different time backends.

The current time namespace proposal just allows you to set the current time separately from the host, which is actually quite a difficult thing to do already (it takes 20 patches)...

[1]: https://lore.kernel.org/lkml/alpine.DEB.2.21.1810022310360.1...

Re: Two Objects Not Namespaced by the Linux Kernel (2017)

#40

Post by cyphar »

briffle wrote: post #11
emmelaich wrote: post #6

Earlier quoted context omitted.

Probably merely because it's hard to do and no one has sufficient motivation. I can think of one good use case -- y2k style problems. Also sometimes apps are tied to external events like legislation. It would be good to set the time forward for testing. You can sort of do this with LD_PRELOAD but it can get hairy. Also see @wmf's comment above.

If there is one thing Y2K taught us, its to ignore any worry about the 2038 problem until 2036, then make a HUGE deal out of it. https://en.wikipedia.org/wiki/Year_2038_problem

Linux and glibc have been working on 2038 problems for at least the past decade.
Post reply on HN