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

Illumos to drop SPARC Support

github.com

Post reply on HN
Print view View original

151–160 of 184 posts

Re: Illumos to drop SPARC Support

#151

Post by wang_li »

arid_eden wrote: post #132
nix23 wrote: post #82

Earlier quoted context omitted.

>Torvalds even said so himself. Torvald's comment about ZFS was as uninformed as it gets...and he calls himself an FS-Guy ;(

His comment was more on the wisdom (or otherwise) of running an out of tree filesystem. I think its hard to disagree with him. He went on to say you would never be able to merge the ZFS tree with Linux. Again he's the one who would know what code gets in Linux. His only actual comment against ZFS was that benchmarks didn't look great - which is unsurprising given all the extra work ZFS is doing wrt data integrity tha…

From the link:

>[ZFS] was always more of a buzzword than anything else, I feel,

This is deeply ignorant. I feel that Linux has been handicapped by the fact that many developers have never done any serious enterprise administration and thus not having clear understanding of the needs of a set of their users.

Re: Illumos to drop SPARC Support

#152

Post by riku_iki »

arid_eden wrote: post #135
nimbius wrote: post #71

Earlier quoted context omitted.

>ZFS on Linux its been said in the thread already but this was always a non-starter. Torvalds even said so himself. CDDL was the last poison pill of a dying giant who couldnt pull its foot from the well. What we, er, the linux community, chose instead, was BTRFS. It isnt ZFS, but its made incredible strides. for most use cases, it is a reasonable and working replacement for ZFS.

My main issue with ZFS is the integrated nature - like systemd for filesystems. My 'alternative' for ZFS isn't BTRFS (awful performance characteristics for my workloads) but LVM coupled with ext4 and mdraid. I get snapshots, reliability, performance and a 'real UNIX' composable toolchain. I miss out on data checksums.

No compression..

Re: Illumos to drop SPARC Support

#153

Post by bombcar »

riku_iki wrote: post #152
arid_eden wrote: post #135

Earlier quoted context omitted.

My main issue with ZFS is the integrated nature - like systemd for filesystems. My 'alternative' for ZFS isn't BTRFS (awful performance characteristics for my workloads) but LVM coupled with ext4 and mdraid. I get snapshots, reliability, performance and a 'real UNIX' composable toolchain. I miss out on data checksums.

No compression..

You could use VDO (I never have) https://access.redhat.com/documentation/en-us/red_hat_enterp...

Re: Illumos to drop SPARC Support

#154

Post by ahl »

mattst88 wrote: post #145
ahl wrote: post #104

I have a uniquely soft spot for SPARC, having written and disassembled a bunch of SPARC early in my career. If this is its swan song, I'll take the moment to share some code the takes advantage of the odd (today) delay slot architecture to implement instruction picking: https://github.com/illumos/illumos-gate/blob/master/usr/src/... The trick uses a branch in the delay slot of a jmp--a decidedly unusual construction.…

Can you explain how that works or what it does? I understand delay slots, but I didn't know it was legal to have a branch in a delay slot, so I don't really know what this means :)

You mean the total lack of comments didn't help? ;-)

SPARC has two attributes (I hesitate to call them features) that this code interacts with: register windows and a delay slot. Register windows are a neat idea that leads to some challenging pathologies, but in short: the CPU has a bunch of registers, say 64, only 24 of which are visible at any moment. There are three classes of windowed registers: %iN (inputs), %lN (local), %oN (output). When you SAVE in a function preamble, the register windows rotate such that the callers %os become your %is and you get a new set of %ls and %os. There are also 8 %gN (global) registers. Problems? There's a fixed number of registers so a bunch of them effectively go to waste; also spilling and filling windows can lead to odd pathologies. The other attribute is the delay slot which simply means that in addition to a %pc you have an %npc (next program counter) and the instruction after a control flow instruction (e.g. branch, jmp, call) is also executed (usually, although branches may "annul" the slot).

This code is in DTrace where we want to know the value of parameters from elsewhere in the stack, but don't want to incur the penalty of a register window flush (i.e. writing all the registers to memory). This code reaches into the register windows to pluck out a particular value. It turns out that for very similar use cases, Bryan Cantrill and I devised the same mechanism completely independently in two unrelated areas of DTrace.

How's it work?

We rotate to the correct register window (note that this instruction is in the delay slot just for swag): https://github.com/illumos/illumos-gate/blob/master/usr/src/...

Then we jmp to %g3 which is an index into the table of instructions below (depending on the register we wanted to snag): https://github.com/illumos/illumos-gate/blob/master/usr/src/...

The subsequent instruction is a branch always (ba) to the next instruction. So:

%pc is the jmp and %npc is the ba. The jmp sets %npc to an instruction in dtrace_getreg_win_table and %pc is the old %npc thus points to the ba. The ba sets %npc to be the label 3f (the wrpr) and %pc is set to the old %npc, the instruction in the table. Finally the particular mov instruction from the table is executed and %pc is set to the old %npc at label 3f.

Why do it this way? Mostly because it was neat. This isn't particularly performance critical code; a big switch statement would probably have worked fine. In the Solaris kernel group I remember talking about interesting constructions like this a bit around the lunch table which is probably why Bryan and I both thought this would be a cool solution.

I'm not aware of another instance of instruction picking in the illumos code base (although the DTrace user-mode tracing does make use of the %pc/%npc split in some cases).

Re: Illumos to drop SPARC Support

#155

Post by dale_glass »

rnd0 wrote: post #142
guardiangod wrote: post #105

Earlier quoted context omitted.

>What we, er, the linux community, chose instead, was BTRFS. Isn't that putting politic before technical excellence, something the Linux crowd is proud of? Other than in place volume expansion, there is no technical reason to choose BTRFS over ZFS (for now.) I don't really see a killer feature from BTRFS that would persuade me to take a chance with it.

>Isn't that putting politic before technical excellence, something the Linux crowd is proud of? It's not unprecedented. The adoption of systemd was forced on distros through political pressure, and not for technical reasons. If you want a truly non-political OS community these days, I think you're basically stuck with OpenBSD. No CoC, no systemd, no political BS at all -just pure tech. (there's other problems with Op…

systemd wasn't "forced" on distros. The distros adopted it because they liked it.

The thing is that systemd did something quite clever -- it sold itself to the people actually building distributions, which are the people that actually matter the most in regards what system software gets used. It made their jobs easier and less annoying in many ways.

As somebody who's done a lot of packaging and writing of SysV scripts, I can tell you that it's a tiresome and annoying task even for a small amount of software, let alone a whole distro. At that point the unix philosophy loses its luster quite a bit.

Re: Illumos to drop SPARC Support

#156

Post by rbanffy »

4ad wrote: post #40
rbanffy wrote: post #2

A fun way to make Oracle donate a machine would be to make an official POWER port. That's a lot of work and I don't see IBM making a machine available.

Convince Oracle to donate a machine... for an Oracle Solaris competitor?! Oracle was the one that shut down OpenSolaris in the first place!

The only way they’d do it is if someone made a Solaris-killer that ran on a SPARC-killer that could run an Oracle-killer database.

But IBM wouldn’t help someone to build an AIX-killer OS.

Re: Illumos to drop SPARC Support

#157

Post by jchw »

tptacek wrote: post #147
jchw wrote: post #89

Earlier quoted context omitted.

Also, tools for improving Docker for multi-tenant workloads exists, like gVisor. I don’t think equivalents exist for jails/zones really.

gVisor isn't a shared-kernel multitenant system; it's essentially kernel emulation. It's a much stronger design.

I mostly mean that it is intended to be a solution to run containers from multiple tenants on the same host. Though I do agree, being essentially a kernel in itself, it is a bit in a different wheelhouse. It still is a huge value add that you can implement something like that on top of Docker, imo.

Re: Illumos to drop SPARC Support

#158

Post by tptacek »

jchw wrote: post #157
tptacek wrote: post #147

Earlier quoted context omitted.

gVisor isn't a shared-kernel multitenant system; it's essentially kernel emulation. It's a much stronger design.

I mostly mean that it is intended to be a solution to run containers from multiple tenants on the same host. Though I do agree, being essentially a kernel in itself, it is a bit in a different wheelhouse. It still is a huge value add that you can implement something like that on top of Docker, imo.

You can run container workloads in "real" VMs too; for instance, check out Kata Containers. Containers are a way of packaging applications; confusingly, they happen to also have a reference standard runtime associated with them. But you don't have to use it.

Re: Illumos to drop SPARC Support

#159

Post by jchw »

tptacek wrote: post #158
jchw wrote: post #157

Earlier quoted context omitted.

I mostly mean that it is intended to be a solution to run containers from multiple tenants on the same host. Though I do agree, being essentially a kernel in itself, it is a bit in a different wheelhouse. It still is a huge value add that you can implement something like that on top of Docker, imo.

You can run container workloads in "real" VMs too; for instance, check out Kata Containers. Containers are a way of packaging applications; confusingly, they happen to also have a reference standard runtime associated with them. But you don't have to use it.

Of course, and that's the value of the abstraction to me. Docker itself is obviously nothing to do with the Linux container technologies themselves that make up the equivalent functionality of FreeBSD jails, but I'm not aware of any equivalent abstraction that works around jails or zones even though it might be possible. So the way I see containers on Linux is not literally a composition of kernel features like cgroups or seccomp, but as an abstract thing that can be composed out of various primitives. And in practice, there's a number of different runtimes around it, including Docker clones like Podman, or tools that manage effectively chroots much closer to what you would do with jails.

That said, I could just be completely wrong, and there could be similar things that can be done using jails and zones. But when I looked around for similar art with FreeBSD jails, either with regards to Docker's style of packaging and distribution, or with regards to additional layers like gVisor, it didn't seem like a thing well-suited to that kind of composition. In comparison, jails, at least, seem kind of like more powerful chroots. To me this is a pretty big difference versus Linux "containers".

Re: Illumos to drop SPARC Support

#160

Post by tptacek »

jchw wrote: post #159
tptacek wrote: post #158

Earlier quoted context omitted.

You can run container workloads in "real" VMs too; for instance, check out Kata Containers. Containers are a way of packaging applications; confusingly, they happen to also have a reference standard runtime associated with them. But you don't have to use it.

Of course, and that's the value of the abstraction to me. Docker itself is obviously nothing to do with the Linux container technologies themselves that make up the equivalent functionality of FreeBSD jails, but I'm not aware of any equivalent abstraction that works around jails or zones even though it might be possible. So the way I see containers on Linux is not literally a composition of kernel features like cgrou…

My mental model of Zones and Jails is that they are a cleaner, more convenient, less error-prone way of expressing a modern, minimally-privileged, locked down Docker runtime. You won't catch me arguing that Zones aren't better than Docker, but the u->k attack surface is untenable for multitenant workloads.
Post reply on HN