DragonFlyBSD Pulls In AMD Radeon Graphics Driver Code From Linux 4.9

[phoronix]

Phoronix: DragonFlyBSD Pulls In AMD Radeon Graphics Driver Code From Linux 4.9

DragonFlyBSD developer François Tigeot has continued doing a good job in continually updating their kernel's graphics driver code with a port of the AMD Radeon graphics source code from the Linux kernel along with related components like TTM memory management...

http://www.phoronix.com/scan.php?page=news_item&px=DragonFlyBSD-Radeon-4.9

[pal666]

lol, it's only 3 years late

[aht0]

lol, it's only 3 years late

It'd be in reverse if AMD was releasing "generic POSIX-compliant" drivers Linux devs then would have to port by themselves. Linux devs would still be porting and reinventing drivers for first gen. GCN cards.

You are getting the driver done by vendor and don't have to do shit besides sitting thumbs up your asses. And gloat, I suppose.

As far as I can tell, there's 1-2 devs working on porting Radeon driver. That's 1-2 non-AMD unpaid volunteer devs more than Linux Radeon driver can show.

"It's only 3 years late, khm, lets make it 13 years later and still no finished BtrFS".Despite bunch of corporations and shitload of devs working on it.
Meanwhile, Dillon finished up Hammer v1, and is working on Hammer v2, all alone.

Productivity-wise, there's no comparison at all.

[pal666]

It'd be in reverse if AMD was releasing "generic POSIX-compliant" drivers Linux devs then would have to port by themselves.

"posix compliant" means userspace - posix doesn't specify kernel internals. which means you have no idea what you are talking about

You are getting the driver done by vendor

isn't that wonderful?

As far as I can tell, there's 1-2 devs working on porting Radeon driver.

imagine how much value they could bring if they weren't wasting their time on this useless task

"It's only 3 years late, khm, lets make it 13 years later and still no finished BtrFS"

nothing is ever finished, btrfs is in production use for many years. and 13 years ago it didn't exist, while your pathetic attempt at analogy requires its existence in current form with proper license in some other kernel.

Meanwhile, Dillon finished up Hammer v1

hammer is not cow, so it is playing in league with ext4, not with btrfs. there is no filesystem as advanced as btrfs on the planet

Productivity-wise, there's no comparison at all.

yep. there are enterprise linux distros defaulting to btrfs, there is no enterprise linux distro defaulting to hammer

[aht0]

"posix compliant" means userspace - posix doesn't specify kernel internals. which means you have no idea what you are talking about
isn't that wonderful?

Not quite. Bunch of system calls exist, which are common for POSIX systems. Nvidia has "platform-independent" driver, just glue around core blob is differing from OS to OS. AMD could, if it wanted to, do something similar - leaving core driver platform-independent and letting OS devs themselves work out the rest. Instead of having to reimplement/work around/emulate missing stuff from completely different OS.

imagine how much value they could bring if they weren't wasting their time on this useless task

Their time, their effort, their decision.
Think how much value you could bring if you didnt waste your time trolling BSD forum and spewing bullshit?

nothing is ever finished, btrfs is in production use for many years. and 13 years ago it didn't exist, while your pathetic attempt at analogy requires its existence in current form with proper license in some other kernel.

I remember with how much fanfare btrfs development started, back in 2007, which,if stretched gives me almost that 13 years. Now, 10+ years later, it's still not fit for mission critical tasks, lacks working RAID5/6 (which for some reason are defined as "corner cases". wth?), Red Hat abandoned it's plan to use it and people in general fawn over "next great file system to come". Typical linux's "lets invent new kind of wheel, again". Reinventing squarish triangles is the real waste of time.

Decide on something's design, implement it throughly, fix the bugs and then keep using it - instead of doing it Linux's Way: half-assed, adding features regardless of existing bugs and after finally getting tired of the resulting unholy mess, finding another "cool ground breaking shiny thing" to repeat the effort on.

hammer is not cow, so it is playing in league with ext4, not with btrfs. there is no filesystem as advanced as btrfs on the planet

Really, ext4..?
Since when ext4 acquired full-blown ECC, snapshots, data deduplication, PFS'ses,master/slave support, fine-grained history or volume support? I am very curious.
H2 has your coveted COW.

Advanced file system that dies or eats your data for unknown reasons, is still broken file system, be it however advanced.

If you don't accept H vs BtrFS analogy, I've got another. Development of ZFS started it 2001, it was announced in 2004. Then it kept acquiring features following 5 years until Oracle got hold of ZFS. By then it was so good that despite fanfare and promises of BtrFS fan club, bunch of people have kept developing it as an "out-of-tree" module. Even after 10+ years of BtrFS. Says all about your "no filesystem as advanced as btrfs on the planet"-claim.

yep. there are enterprise linux distros defaulting to btrfs, there is no enterprise linux distro defaulting to hammer

Last I heard RHEL abandoned it.. googling about SLES gave me article "how to diagnostic and repair btrfs" as a first link. Says it all.
Oracle has XFS like RHEL, since it's basically re-branded RHEL with Oracle's patches.

There were in fact couple of attempts at porting Hammer v1 to Linux. They got nowhere because some of the things in Linux kernel would have to be fundamentally changed first. If you are interested I can dig out M.Dillon's explanation, what is required for porting Hammer without reverting to half-baked FUSE ports or read-only file system support.

[profoundWHALE]

Btrfs is the reason why Bcachefs and Hammer exists.

[aht0]

Btrfs is the reason why Bcachefs and Hammer exists.

Dillon could have just used ZFS (no license restrictions for ZFS+BSD, remember), instead of writing his own file system from scratch. So BtrFS has probably not much to do there.

He probably took that up as "preparative work" with the end-goal of writing proper file system fit for clusters. Timelines kind of fit, because DragonFly's SMP implementation has been in 'finished' stage for some years (just getting fixes) and at the same time he has required experience from writing Hammer v1 and bunch done writing Hammer v2.