Porting FreeBSD drm2 driver
I just noticed that FreeBSD's new 9.1 release has Kernel Mode Setting: The drm2(4) Intel GPU driver, which supports GEM and KMS and works with new generations of GPUs such as IronLake, SandyBridge, and IvyBridge, has been added. The agp(4) driver now supports SandyBridge and IvyBridge CPU northbridges.[r236926, r236927, r239965] (from http://www.freebsd.org/releases/9.1R/relnotes.html) It seems that it is practically impossible to buy a PCI graphics card these days for which X doesn't require KMS. This is going to make the use of NetBSD with X impossible at a very rapid rate. Even the card I that thought was supported properly (Radeon HD 5450-based) isn't - X claims no accelleration. I haven't tried Xv yet (needed to view video) but I fear the worst. Is anybody by any chance working on porting this FreeBSD driver to NetBSD? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'
Re: Porting FreeBSD drm2 driver
In article 20130112154830.gc22...@falu.nl, Rhialto rhia...@falu.nl wrote: I just noticed that FreeBSD's new 9.1 release has Kernel Mode Setting: The drm2(4) Intel GPU driver, which supports GEM and KMS and works with new generations of GPUs such as IronLake, SandyBridge, and IvyBridge, has been added. The agp(4) driver now supports SandyBridge and IvyBridge CPU northbridges.[r236926, r236927, r239965] (from http://www.freebsd.org/releases/9.1R/relnotes.html) It seems that it is practically impossible to buy a PCI graphics card these days for which X doesn't require KMS. This is going to make the use of NetBSD with X impossible at a very rapid rate. Even the card I that thought was supported properly (Radeon HD 5450-based) isn't - X claims no accelleration. I haven't tried Xv yet (needed to view video) but I fear the worst. Is anybody by any chance working on porting this FreeBSD driver to NetBSD? We are painfully aware of this and we are commissioning work to remedy the situation. christos
Re: Porting FreeBSD drm2 driver
On Sat 12 Jan 2013 at 16:09:27 +, Christos Zoulas wrote: We are painfully aware of this and we are commissioning work to remedy the situation. Ah, that is great to hear. Thank you! christos -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'
Re: Importing lua(4), but where in the source tree?
Hi, From: Marc Balmer m...@msys.ch, Date: Mon, 7 Jan 2013 22:11:38 +0100 I want to import the lua(4) device driver, which is currently a module only, which seems wrong. Is sys/dev/lua/ a good place? Nowadays I am playing with lua in userland. Current lua in base userland is 5.1.5 and it seems that it lacks bitwise operation commands. According to Lua website, newer 5.2 have bitwise operations, bit32.band etc. What version of Lua will be imported? I have no idea about kernel manner, but I think Lua 5.2 is preferable for kernel use, because bitwise operations are more important in kernel. Thank you. -- Ryo ONODERA // ryo...@yk.rim.or.jp PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: Importing lua(4), but where in the source tree?
Am 12.01.2013 um 21:15 schrieb Ryo ONODERA ryo...@yk.rim.or.jp: Hi, From: Marc Balmer m...@msys.ch, Date: Mon, 7 Jan 2013 22:11:38 +0100 I want to import the lua(4) device driver, which is currently a module only, which seems wrong. Is sys/dev/lua/ a good place? Nowadays I am playing with lua in userland. Current lua in base userland is 5.1.5 and it seems that it lacks bitwise operation commands. According to Lua website, newer 5.2 have bitwise operations, bit32.band etc. What version of Lua will be imported? I have no idea about kernel manner, but I think Lua 5.2 is preferable for kernel use, because bitwise operations are more important in kernel. For the time being it is Lua 5.1.4 (and that is already in the tree, so Lua does not get imported, it just gets used in the kernel as well). Once all is in place I will start to update everything to Lua 5.2. Does that sound OK to you? - Marc
Re: Importing lua(4), but where in the source tree?
Hi, From: Marc Balmer m...@msys.ch, Date: Sat, 12 Jan 2013 21:24:50 +0100 Am 12.01.2013 um 21:15 schrieb Ryo ONODERA ryo...@yk.rim.or.jp: Hi, From: Marc Balmer m...@msys.ch, Date: Mon, 7 Jan 2013 22:11:38 +0100 I want to import the lua(4) device driver, which is currently a module only, which seems wrong. Is sys/dev/lua/ a good place? Nowadays I am playing with lua in userland. Current lua in base userland is 5.1.5 and it seems that it lacks bitwise operation commands. According to Lua website, newer 5.2 have bitwise operations, bit32.band etc. What version of Lua will be imported? I have no idea about kernel manner, but I think Lua 5.2 is preferable for kernel use, because bitwise operations are more important in kernel. For the time being it is Lua 5.1.4 (and that is already in the tree, so Lua does not get imported, it just gets used in the kernel as well). Once all is in place I will start to update everything to Lua 5.2. Does that sound OK to you? O.k. to me. Thank you! -- Ryo ONODERA // ryo...@yk.rim.or.jp PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
revert broken O_SEARCH
The following (untested) patch reverts the defective O_SEARCH
implementation that was committed along with the *at calls back in
November.
I am currently building and testing it and will commit it when that
finishes.
I have left O_SEARCH defined and visible and made open() explicitly
ignore it. This way, most code that tries to use it will continue to
build and run. I've also arranged lib/libc/c063/t_o_search.c so that
the tests that make use of the O_SEARCH semantics will disappear until
O_SEARCH comes back, and fixed some mistakes and/or incorrect hacks
that were causing some of these to succeed despite the broken O_SEARCH
implementation.
The man page changes at the end are essentially all the same.
--
diff -r 660c8bed4e78 sys/kern/vfs_syscalls.c
--- a/sys/kern/vfs_syscalls.c Sat Jan 12 15:03:39 2013 -0500
+++ b/sys/kern/vfs_syscalls.c Sat Jan 12 18:24:09 2013 -0500
@@ -181,14 +181,6 @@
if ((error = fd_getvnode(fdat, dfp)) != 0)
goto out;
- if (!(dfp-f_flag FSEARCH)) {
- vn_lock(dfp-f_data, LK_EXCLUSIVE);
- error = VOP_ACCESS(dfp-f_data, VEXEC, l-l_cred);
- VOP_UNLOCK(dfp-f_data);
- if (error)
- goto cleanup;
- }
-
NDAT(ndp, dfp-f_data);
}
@@ -213,14 +205,6 @@
if ((error = fd_getvnode(fdat, dfp)) != 0)
goto out;
- if (!(dfp-f_flag FSEARCH)) {
- vn_lock(dfp-f_data, LK_EXCLUSIVE);
- error = VOP_ACCESS(dfp-f_data, VEXEC, l-l_cred);
- VOP_UNLOCK(dfp-f_data);
- if (error)
- goto cleanup;
- }
-
dvp = dfp-f_data;
} else {
dvp = NULL;
@@ -1577,6 +1561,10 @@
int indx, error;
struct nameidata nd;
+ if (open_flags O_SEARCH) {
+ open_flags = ~(int)O_SEARCH;
+ }
+
flags = FFLAGS(open_flags);
if ((flags (FREAD | FWRITE)) == 0)
return EINVAL;
@@ -1641,7 +1629,6 @@
/*
* Check permissions, allocate an open file structure,
* and call the device open routine if any.
- * XXX implement O_SEARCH
*/
static int
do_sys_openat(lwp_t *l, int fdat, const char *path, int flags,
@@ -1662,19 +1649,10 @@
goto out;
dvp = dfp-f_data;
-
- if (!(dfp-f_flag FSEARCH)) {
- vn_lock(dfp-f_data, LK_EXCLUSIVE);
- error = VOP_ACCESS(dfp-f_data, VEXEC, l-l_cred);
- VOP_UNLOCK(dfp-f_data);
- if (error)
- goto cleanup;
- }
}
error = do_open(l, dvp, pb, flags, mode, fd);
-cleanup:
if (dfp != NULL)
fd_putfile(fdat);
out:
@@ -1988,6 +1966,10 @@
0, NULL, NULL, NULL)))
return (error);
+ if (oflags O_SEARCH) {
+ oflags = ~(int)O_SEARCH;
+ }
+
flags = FFLAGS(oflags);
if ((flags (FREAD | FWRITE)) == 0)
return (EINVAL);
diff -r 660c8bed4e78 sys/sys/fcntl.h
--- a/sys/sys/fcntl.h Sat Jan 12 15:03:39 2013 -0500
+++ b/sys/sys/fcntl.h Sat Jan 12 18:24:09 2013 -0500
@@ -131,7 +131,7 @@
#defineO_MASK
(O_ACCMODE|O_NONBLOCK|O_APPEND|O_SHLOCK|O_EXLOCK|\
O_ASYNC|O_SYNC|O_CREAT|O_TRUNC|O_EXCL|O_DSYNC|\
O_RSYNC|O_NOCTTY|O_ALT_IO|O_NOFOLLOW|O_DIRECT|\
-O_DIRECTORY|O_CLOEXEC|O_NOSIGPIPE|O_SEARCH)
+O_DIRECTORY|O_CLOEXEC|O_NOSIGPIPE)
#defineFMARK 0x1000 /* mark during gc() */
#defineFDEFER 0x2000 /* defer for next gc pass */
@@ -141,7 +141,7 @@
#defineFKIOCTL 0x8000 /* kernel originated ioctl */
/* bits settable by fcntl(F_SETFL, ...) */
#defineFCNTLFLAGS
(FAPPEND|FASYNC|FFSYNC|FNONBLOCK|FDSYNC|FRSYNC|FALTIO|\
-FDIRECT|FNOSIGPIPE|FSEARCH)
+FDIRECT|FNOSIGPIPE)
/* bits to save after open(2) */
#defineFMASK (FREAD|FWRITE|FCNTLFLAGS)
#endif /* _KERNEL */
@@ -166,7 +166,6 @@
#defineFRSYNC O_RSYNC /* kernel */
#defineFALTIO O_ALT_IO/* kernel */
#defineFDIRECT O_DIRECT/* kernel */
-#defineFSEARCH O_SEARCH/* kernel */
#endif
/*
diff -r 660c8bed4e78 tests/lib/libc/c063/t_o_search.c
--- a/tests/lib/libc/c063/t_o_search.c Sat Jan 12 15:03:39 2013 -0500
+++ b/tests/lib/libc/c063/t_o_search.c Sat Jan 12 18:24:09 2013 -0500
@@ -42,14 +42,24 @@
#include pwd.h
#include sys/param.h
+/*
+ * dholland 20130112: disable tests that require O_SEARCH
