/tech/ - Technology★

Hmm, after re-reading the name is sound a lot like Universal Hardware description format and I think this already exists. Too bad we most often don't know enough about the Hardware to make this happen.

having drivers obscured and locked into the eco system is part of the plan.

Couldn't a hypothetical new kernel implement Linux's driver API to run Linux drivers? IIRC, they wanted to do this with Genode. Maybe even run whole Linux as a module, with fake virtual drivers for everything that's not going to run with Linux drivers, but I imagine that's gonna have a good overhead.

Your CPU itself has many layers as well, the intel management engine even has an ssh-server running (cia-nigger backdoor)

>>976482

that has been done but linux kernel changes the api with each new version, so you'll either be stuck with one specific linux version or you'll have to re-write it each time.

>>976473 (OP)

I think the easiest way to gain traction is to limit your focus to specific hardware. Like one or a few sbpc's.

That way you can larp as Be Inc. without getting bogged down in hardware.

>>976473 (OP)

The solution is not a way of managing the useless abstraction that is the driver model but rather to get back to directly programming the hardware.

>>976489

That has also been done before. Once it support is completed, it's outdated hardware is either broken or not longer avaible on the market.

Any "community" hardware project always ended in either:

"Oops, it failed. Thanks for the donations though. Had nice vacation because of it, hehehehe"

or

"There it is! Just like promised! Don't mind those properitary driver blobs we added, there is absolutely nothing suspicious going on, hehehehe".

or

"Yeah, after 10 years of development we present underpowered and artificially limited thing and it only costs you 200 times more than any comparible hardware on the marked! Well, freedom has it's price, hehehehe".

So I'm not against concentrating on specific hardware but if it's comercial/ china or something it usually will imediately be taken from the marked once it's pried open for freedom.

>>976492

>While this would surely produce more efficient, faster and un-bloated, this usually also kinda means it's not exactly portable code and usually cannot be reused on new hardware and a re-write from scratch often be the more sane solution.

>However, most Hardware Documentation comes with NDAs and other wierd shit, already stiffling driver development as it is.

>>976497

Just target something like the sjwPi. Since you can still get the first one so they have reasonably support, and everyone has one gathering dust anyway.

You still have the blobs to deal with though on some boards. But since the community is so massive, there is at least some effort exerted on getting rid of those blobs. At least when you compare it to generic chink board 658.

>traction

we dont give a fuck nigger everything is shit otherwise id be using it and writing my own drivers and software if i have to

>>976531

>Olimex

last time I looked they claimed to be in favor of open hardware (they released some files too) but for that one laptop thingy they refused to make something 100% free software (even though they could have), said they don't care about that or something.

>>976473 (OP)

That's what ACPI does (for a specific subset of hardware and if I understand it correctly) and look how that works out. Lots of ACPI capable hardware has quirks that driver developers have to work around.

>>976561

I think they just release their own board designs as open, with schematics and such. But the chips on them, they don't make those. So in the case of Allwinner SoC's, they don't own that and can't release any open drivers for it, because they don't have the full documentation to it. Only Allwinner and/or whoever makes that Mali GPU has this.

AFAIK, there isn't any completely open hardware for ARM boards, much less x86. So it's a matter of degrees. The more open it is, the better for us. With that RPi shit, you can't even start the ARM cores without their blob. Or you can use that rpi-open-firware thing and start the cores but have a computer with very little functionality. None of that is interesting to me. At least I can use a software framebuffer to run a console or Xorg. Hell, I've been stuck doing that anyway with my past two laptops since one had an Nvidia GPU (T61p), and the current one was simply too new to have a driver in OpenBSD. And now that there is a working driver, the laptop is broken. So I'm getting the hell away from these laptops. TBQH, their build quality is shit now anyway, and the last good one I touched was an IBM Thinkpad (not that T61p, other ones from before Lenovo took over). But they all have the Intel botnet (bugnet?), so I wouldn't want them now anyway.

>>976531

> This board will be available forever

Why do you believe that?

I think you would be better off describing the actual hardware interface more formally rather than a whole driver. How exactly you want to drive your hardware is a part of your OSs unique design. Look into interface description languages, which are used most often for rpc.

Regarding implementing drivers for a new operating system, a lot of that grunt work can be done for you using code generation based on an IDL. The interesting bits of your drivers should be new anyway, you do want something different from linux yes?

>>976593

Click on the word and they clarify what they mean.

>>976603

no idea. I can program an µC to put it's pins to high or low and that just might let some letters appear on a small LCD but once the OS abstraction layer comes, like on a PC, I have no idea what's going on anymore. It's simply going over my head.

I simply thought, drivers aren't just hardware interfaces. There is some communication going on and that's what actually makes the difference, doesn't it?

>you want something different from linux

that's the reason for this thread. translate linux drivers and it's functions to something more abstract and then you have some "logic" you could implement in your own kernel and are not limited by linux design.

>>976593

>>976604

>Available forever

>When there is enough demand

>Demand is 50k pieces

Hmm, they actually claim they ordered 50k at once, so I guess that settles it.

>>976473 (OP)

The basic problem is that linux doesn't guarantee ABI stability. If they did, you could just write drivers as kernel modules, then create a new kernel exporting the same interface. Why doesn't linux have a stable ABI?

>>976657

It probably helps too that they also produce boards rated for industrial use. With consumer-only stuff, the demand falls more quickly. But I guess the same SoCs are used both in industrial and consummer boards. It must be actual PCB and other components that are different (like maybe having more/better capacitors and whatnot).

>>976512

this is cool, what's it from?