Re: A TrustedBSD voluntary sandbox policy.
On Thu, 8 Nov 2007, Andrea Campi wrote: On Wed, Nov 07, 2007 at 10:20:28PM -0500, [EMAIL PROTECTED] wrote: I'm considering developing a policy/module for TrustedBSD loosely based on the systrace concept - A process loads a policy and then executes another program in a sandbox with fine grained control over what that program can do. ... Please note that the 'policy' given on the command line is purely for the sake of example, no syntax or semantics have been decided upon. Can't comment on the implementation or wider issues, but if you pursue this, please have a look at how MacOS Leopard does it (Seatbelt). Would be nice to converge on both syntax (a Schema dialect) and tools names / command line args--or if converging is not possible, at least know where and why and make a conscious decision. FYI, Seatbelt is based on the Mac OS X port of the TrustedBSD MAC Framework, which while it has some significant changes (some now present in the 8-CURRENT branch of FreeBSD), may well be a good starting point. Last I checked, the source for Seatbelt wasn't yet available, but there was hope it would be available in the near future. A port of the policy to FreeBSD sounds like it would be very interesting to do, and might provide a nice starting point rather than having to write up a policy from scratch. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround.
On fre, nov 02, 2007 at 01:34:51 +0300, Alexander Sabourenkov wrote: Hello. I have ported the workaround for the hardware bug that causes data corruption on Promise SATA300 TX4 cards to RELENG_7. Bug description: SATA300 TX4 hardware chokes if last PRD entry (in a dma transfer) is larger than 164 bytes. This was found while analysing vendor-supplied linux driver. Workaround: Split trailing PRD entry if it's larger that 164 bytes. Two supplied patches do fix problem on my machine. There is, however, a style problem with them. It seems like PRD entry count is limited at 256. I have not found a good way to guarantee that one entry is always available to do the split, thus the ugly solution of patching ata-dma.c. Patches, patched and original files are at http://lxnt.info/tx4/freebsd/. Hi, I tried the patch, but I end up with the partition table being incorrectly read (probably) on the drives connected to my TX4 card. Normally, there's one partition on the drive, but when I apply the patch, the drive provider (ad6) is all that shows up in /dev. When I revert the patch, the partition (ad6s1) shows up in /dev again. I applied both the ata-chipset patch and ata-dma patch to a RELENG_7 system. -- Ulf Lilleengen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Would like some simple volunteer work
Hi, I'm a cs student from Australia. Just want to enhance my skills and hopefully benefit this online software community in some way. I enjoy C programming in particular, havn't really mastered it or other languages. I'd like to practice by doing whatever though if anybody understands where i'm coming from. Is this a good place to do this? Cheers -- *** Frederick James Bertram (08)93371109 10 Snook Crescent Hilton 6163 Western Australia - * ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Would like some simple volunteer work
On Nov 16, 2007 10:40 AM, Fred Bertram [EMAIL PROTECTED] wrote: Hi, I'm a cs student from Australia. Just want to enhance my skills and hopefully benefit this online software community in some way. I enjoy C programming in particular, havn't really mastered it or other languages. I'd like to practice by doing whatever though if anybody understands where i'm coming from. Is this a good place to do this? Cheers -- *** Frederick James Bertram (08)93371109 10 Snook Crescent Hilton 6163 Western Australia - * People to tend to mail this and ask what they can do to help. Easiest thing is just to check out the source, find what ever intrests you and start to hack. Check out the PR database and find and error and try and solve it. It's not gonna be fun if anybody tells you what to do, you need to find what you find fun to do and then just do it. br dunceor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
On Wed, 14 Nov 2007, Skip Ford wrote: I agree regarding the duplication with ps(1) -- however, I'm generally of the opinion that ps(1) is overburdened as tools go, and that the goals are actually somehwat different--procstat(1) intentionally doesn't have the ability to generate a list of processes, for example, taking pids explicitly as the argument; likewise, historically ps(1) has not been interested in printing more than one line per process (although I think -h changed this). I'll do a bit more investigation as to how easily it can be wedged in, and do recognize the concern here. I understand, and I sort of knew that from the beginning which is why I didn't provide feedback immediately. I don't have a suggestion as to what I think should be done. While procstat(1) currently takes a list of pids, I wouldn't be surprised if somebody adds code to list all processes, unless you block it. I think it would be useful, especially since some of it's options produce single-line per pid output, such as credentials. The two utilities do provide different information, it's just a little odd to have two utilities with basically the same name. But I can't think of a more appropriate name for procstat(1). FWIW, it looks like on Solaris, there are a series of psig(1), pstack(1), ptree(1), etc, tools for similar sorts of per-process inspection purposes. I think I prefer bundling it into a single tool, but it's certainly a similar idea. Maybe I should just rename procstat(1) to pinfo(1) and be done with it? Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Would like some simple volunteer work
On Nov 16, 2007 1:11 AM, Karl Sjodahl - dunceor [EMAIL PROTECTED] wrote: On Nov 16, 2007 10:40 AM, Fred Bertram [EMAIL PROTECTED] wrote: Hi, I'm a cs student from Australia. Just want to enhance my skills and hopefully benefit this online software community in some way. I enjoy C programming in particular, havn't really mastered it or other languages. I'd like to practice by doing whatever though if anybody understands where i'm coming from. Is this a good place to do this? Cheers -- *** Frederick James Bertram (08)93371109 10 Snook Crescent Hilton 6163 Western Australia - * People to tend to mail this and ask what they can do to help. Easiest thing is just to check out the source, find what ever intrests you and start to hack. Check out the PR database and find and error and try and solve it. It's not gonna be fun if anybody tells you what to do, you need to find what you find fun to do and then just do it. br dunceor The PR database is really the best place to start if you're really interested in helping. There are lots of small tasks there. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Would like some simple volunteer work
Quoting Fred Bertram [EMAIL PROTECTED] (from Fri, 16 Nov 2007 17:40:23 +0800): Just want to enhance my skills and hopefully benefit this online software community in some way. I enjoy C programming in particular, havn't really mastered it or other languages. I'd like to practice by doing whatever though if anybody understands where i'm coming from. As people told you already: the PR database is a good start. Don't be afraid if you don't understand something. Either proceed to the next problem, or just try to start (often a problem looks big from far away, but when you go closer and look around, it's not that big anymore). In case you can not find answers (in our man pages or the source) to questions you come up with while looking at a problem, feel free to ask on the lists (pick one which seems appropriate for the topic you need an answer for). If at some point you feel more confident in what you can do, and you want to do something else than solving problems in our PR database: we also have the ideas list (http://www.freebsd.org/projects/ideas/). It's not a TODO list, it's an ideas list. Projects without technical contacts need an investigation if it is beneficial to have it in FreeBSD or not. It does not contain everything, some specific subprojects have for example a real TODO list. If you provide patches, don't feel bad if someone moans about the quality (it may or may not happen, we are in a public place and all kinds of persons are around). Take it as an opportunity to improve (either the patches, or the way of the presentation/explanation). Bye, Alexander. -- Although the moon is smaller than the earth, it is farther away. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Would like some simple volunteer work
Alexander Leidinger wrote: Although the moon is smaller than the earth, it is farther away. George Bush? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Would like some simple volunteer work
Quoting Julian Elischer [EMAIL PROTECTED] (Fri, 16 Nov 2007 10:47:33 -0800): Alexander Leidinger wrote: Although the moon is smaller than the earth, it is farther away. George Bush? I don't know. It's output from fortune, so you can look up the history. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround.
Ulf Lilleengen wrote:
I tried the patch, but I end up with the partition table being incorrectly
read (probably) on the drives connected to my TX4 card. Normally, there's
one partition on the drive, but when I apply the patch, the drive provider
(ad6) is all that shows up in /dev.
When I revert the patch, the partition (ad6s1) shows up in /dev again.
I applied both the ata-chipset patch and ata-dma patch to a RELENG_7 system.
You should try the attached official patch and let me know if that
helps, thanks!
-Søren
? promise-fix2
Index: ata-chipset.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-chipset.c,v
retrieving revision 1.202.2.2
diff -u -r1.202.2.2 ata-chipset.c
--- ata-chipset.c 31 Oct 2007 19:59:53 - 1.202.2.2
+++ ata-chipset.c 11 Nov 2007 17:08:49 -
@@ -142,6 +142,7 @@
static int ata_promise_mio_command(struct ata_request *request);
static void ata_promise_mio_reset(device_t dev);
static void ata_promise_mio_dmainit(device_t dev);
+static void ata_promise_mio_setprd(void *xsc, bus_dma_segment_t *segs, int
nsegs, int error);
static void ata_promise_mio_setmode(device_t dev, int mode);
static void ata_promise_sx4_intr(void *data);
static int ata_promise_sx4_command(struct ata_request *request);
@@ -792,6 +793,7 @@
prd[i].dbc = htole32((segs[i].ds_len - 1) ATA_AHCI_PRD_MASK);
}
}
+KASSERT(nsegs = ATA_DMA_ENTRIES, too many DMA segment entries\n);
args-nsegs = nsegs;
}
@@ -2760,6 +2762,8 @@
prd[i].addrhi = htole32((u_int64_t)segs[i].ds_addr 32);
}
prd[i - 1].count |= htole32(ATA_DMA_EOT);
+KASSERT(nsegs = ATA_DMA_ENTRIES, too many DMA segment entries\n);
+args-nsegs = nsegs;
}
static void
@@ -3288,9 +3292,13 @@
/* prime fake interrupt register */
ATA_OUTL(ctlr-r_res2, fake_reg, 0x);
- /* clear SATA status */
+ /* clear SATA status and unmask interrupts */
ATA_OUTL(ctlr-r_res2, stat_reg, 0x00ff);
+ /* enable long burst lenght on gen2 chips */
+ if ((ctlr-chip-cfg2 == PRSATA2) || (ctlr-chip-cfg2 == PRCMBO2))
+ ATA_OUTL(ctlr-r_res2, 0x44, ATA_INL(ctlr-r_res2, 0x44) | 0x2000);
+
ctlr-allocate = ata_promise_mio_allocate;
ctlr-reset = ata_promise_mio_reset;
ctlr-dmainit = ata_promise_mio_dmainit;
@@ -3778,8 +3786,42 @@
static void
ata_promise_mio_dmainit(device_t dev)
{
+struct ata_channel *ch = device_get_softc(dev);
+
/* note start and stop are not used here */
ata_dmainit(dev);
+if (ch-dma)
+ ch-dma-setprd = ata_promise_mio_setprd;
+}
+
+
+#define MAXLASTSGSIZE (32 * sizeof(u_int32_t))
+static void
+ata_promise_mio_setprd(void *xsc, bus_dma_segment_t *segs, int nsegs, int
error)
+{
+struct ata_dmasetprd_args *args = xsc;
+struct ata_dma_prdentry *prd = args-dmatab;
+int i;
+
+if ((args-error = error))
+ return;
+
+for (i = 0; i nsegs; i++) {
+ prd[i].addr = htole32(segs[i].ds_addr);
+ prd[i].count = htole32(segs[i].ds_len);
+}
+if (segs[i - 1].ds_len MAXLASTSGSIZE) {
+ //printf(split last SG element of %u\n, segs[i - 1].ds_len);
+ prd[i - 1].count = htole32(segs[i - 1].ds_len - MAXLASTSGSIZE);
+ prd[i].count = htole32(MAXLASTSGSIZE);
+ prd[i].addr = htole32(segs[i - 1].ds_addr +
+ (segs[i - 1].ds_len - MAXLASTSGSIZE));
+ nsegs++;
+ i++;
+}
+prd[i - 1].count |= htole32(ATA_DMA_EOT);
+KASSERT(nsegs = ATA_DMA_ENTRIES, too many DMA segment entries\n);
+args-nsegs = nsegs;
}
static void
@@ -4849,6 +4891,8 @@
prd[i].count = htole32(segs[i].ds_len);
}
prd[i - 1].control = htole32(ATA_DMA_EOT);
+KASSERT(nsegs = ATA_DMA_ENTRIES, too many DMA segment entries\n);
+args-nsegs = nsegs;
}
static void
Index: ata-dma.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-dma.c,v
retrieving revision 1.147
diff -u -r1.147 ata-dma.c
--- ata-dma.c 8 Apr 2007 21:53:52 - 1.147
+++ ata-dma.c 11 Nov 2007 17:08:49 -
@@ -213,6 +213,7 @@
prd[i].count = htole32(segs[i].ds_len);
}
prd[i - 1].count |= htole32(ATA_DMA_EOT);
+KASSERT(nsegs = ATA_DMA_ENTRIES, too many DMA segment entries\n);
args-nsegs = nsegs;
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
rpcgen issues on ports/security/cfs
Hello, I needed to get the security/cfs port running on a FreeBSD 7 machine, but it didn't compile at all. The issue was that rpcgen created code like: extern void * admproc_null_2(void *, CLIENT *); extern void * admproc_null_2_svc(void *, struct svc_req *); #defineADMPROC_ATTACH ((unsigned long)(1)) but what worked was: extern void * admproc_null_2(void *, CLIENT *); #define admproc_null_2_svc admproc_null_2 #defineADMPROC_ATTACH ((unsigned long)(1)) (instead of prototyping the _svc function, just make it the same as the non _svc version) And: #defineNFSPROC_SETATTR ((unsigned long)(2)) extern attrstat * nfsproc_setattr_2(sattrargs *, CLIENT *); extern attrstat * nfsproc_setattr_2_svc(sattrargs *, struct svc_req *); but what worked was: #defineNFSPROC_SETATTR ((unsigned long)(2)) extern attrstat * nfsproc_setattr_2(sattrargs *, SR *); #define nfsproc_setattr_2_svc nfsproc_setattr_2 (instead of a CLIENT *, have a SR *) That is all code generated by rpcgen. I tried to run rpcgen with the -b option, but that didn't really work. I'm really without a clue here on how to resolve this, not knowing what rpcgen really does do. But I know that the binaries posted to http://www.mavetju.org/~edwin/cfs-1.4.1-7.0.tar.gz do work on FreeBSD 7.0 and that I'm more than happy to see if I can get it up and running with different options than patched the code generated by rpcgen :-) Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Would like some simple volunteer work
On Nov 16, 2007, at 12:47 PM, Julian Elischer wrote: Alexander Leidinger wrote: Although the moon is smaller than the earth, it is farther away. George Bush? I mow my lawn. - Eric F Crist Secure Computing Networks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Would like some simple volunteer work
Fred Bertram wrote: Hi, I'm a cs student from Australia. Just want to enhance my skills and hopefully benefit this online software community in some way. I enjoy C programming in particular, havn't really mastered it or other languages. I'd like to practice by doing whatever though if anybody understands where i'm coming from. Is this a good place to do this? *** Frederick James Bertram Hilton 6163 Western Australia sure it is. But it is up to you to decide what you would like to do, and realise that not every change that is submitted is accepted. Sometimes things that appear as obvious problems turn out to be there for reasons that are not at all obvious, so before you try fixing things it's usually a good policy to ask on the mailing list if it is something that SHOULD be done. there is a list at http://www.freebsd.org/projects/ideas/ pick something simple, subscribe to [EMAIL PROTECTED] discuss your ideas. code *fame* :-) Julian Elischer Daglish, Western Australia. (no, not really.. I have a house there but I'm in the US at the moment) talk to [EMAIL PROTECTED] he's somewhere in Perth there.) Cheers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
Robert Watson wrote: On Wed, 14 Nov 2007, Skip Ford wrote: I agree regarding the duplication with ps(1) -- however, I'm generally of the opinion that ps(1) is overburdened as tools go, and that the goals are actually somehwat different--procstat(1) intentionally doesn't have the ability to generate a list of processes, for example, taking pids explicitly as the argument; likewise, historically ps(1) has not been interested in printing more than one line per process (although I think -h changed this). I'll do a bit more investigation as to how easily it can be wedged in, and do recognize the concern here. I understand, and I sort of knew that from the beginning which is why I didn't provide feedback immediately. I don't have a suggestion as to what I think should be done. While procstat(1) currently takes a list of pids, I wouldn't be surprised if somebody adds code to list all processes, unless you block it. I think it would be useful, especially since some of it's options produce single-line per pid output, such as credentials. The two utilities do provide different information, it's just a little odd to have two utilities with basically the same name. But I can't think of a more appropriate name for procstat(1). FWIW, it looks like on Solaris, there are a series of psig(1), pstack(1), ptree(1), etc, tools for similar sorts of per-process inspection purposes. I think I prefer bundling it into a single tool, but it's certainly a similar idea. Maybe I should just rename procstat(1) to pinfo(1) and be done with it? Either of those options works for me. If I were the first person ever to make the decision, I'd go with pinfo(1). However, Linux doesn't have separate utilities like Solaris but does have a procinfo(8) utility in addition to their ps(1). Their procinfo(8) displays system status as gathered from procfs. In other words, anything that's not process related that's available via procfs gets displayed with procinfo(8). So, needless to say, it isn't per-process like ours would be nor does it provide anywhere near the same type of information as pinfo(1) currently (or ever) would: http://www.linuxcommand.org/man_pages/procinfo8.html So, even though the Solaris way of separate utilities seems like overkill to me, that's what I'd vote for following. If that's what you decide should be done and you want a hand, I can do the work. Just let me know the names of the utilities and supply Solaris manpages if they have matching commands, and I can convert your code so you can be working on bigger and better things. But, again, even pinfo(1) would be better than procstat(1) to me so if that's what you decide, I don't have a problem with that. At least our two utilities wouldn't have essentially the same name. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
Robert Watson wrote: On Wed, 14 Nov 2007, Skip Ford wrote: I agree regarding the duplication with ps(1) -- however, I'm generally of the opinion that ps(1) is overburdened as tools go, and that the goals are actually somehwat different--procstat(1) intentionally doesn't have the ability to generate a list of processes, for example, taking pids explicitly as the argument; likewise, historically ps(1) has not been interested in printing more than one line per process (although I think -h changed this). I'll do a bit more investigation as to how easily it can be wedged in, and do recognize the concern here. I understand, and I sort of knew that from the beginning which is why I didn't provide feedback immediately. I don't have a suggestion as to what I think should be done. While procstat(1) currently takes a list of pids, I wouldn't be surprised if somebody adds code to list all processes, unless you block it. I think it would be useful, especially since some of it's options produce single-line per pid output, such as credentials. The two utilities do provide different information, it's just a little odd to have two utilities with basically the same name. But I can't think of a more appropriate name for procstat(1). FWIW, it looks like on Solaris, there are a series of psig(1), pstack(1), ptree(1), etc, tools for similar sorts of per-process inspection purposes. I think I prefer bundling it into a single tool, but it's certainly a similar idea. Maybe I should just rename procstat(1) to pinfo(1) and be done with it? How about renaming procstat(1) to proc(1), rolling up all of the Solaris proc tools functionality into that (someday), then creating hardlinks for all of the individual utilities? I just found the Solaris manpage for their proc tools and I really like how they've done it. The first command listed on that page is proc but then it isn't listed in the synopsis and no man page is listed in the links. So, that plus their single proc tools manpage makes it look to me like that's what they actually do, use a single utility with hardlinks. I've never used Solaris or seen the source so I could be wrong, but that's how it looks from the manpage. That's a great solution, IMO. Plus, it would buy more time. It could go in immediately to all branches then be improved later without breaking anything. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Patch for ping6 -o
On Thu, 15 Nov 2007, 12:01-, Dima Dorfman wrote: The ping(8) utility has an -o switch that tells it to exit after receiving the first reply. This is useful, but ping6(8) doesn't have it. Simple patch attached. Comments/reviews/whatnots? I'll commit to HEAD in a few days if I don't hear any objections. You forgot to update usage(). -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Any hope to have things requested by NVidia in FreeBSD-7?
I read long time ago that the reason that NVidia can't have their driver on 64-bit platform is that FreeBSD kernel lacks some functionality. Is this functionality present in 7.0? Or when to expect this to be done? I have NVidia card but still run 32-bit system because of lack of driver. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any hope to have things requested by NVidia in FreeBSD-7?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is this functionality present in 7.0? Or when to expect this to be done? Most of the tasks have been spoken for but very little news so far on progess - -- Aryeh M. Friedman Developer, not business, friendly http://www.flosoft-systems.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHPhzBJ9+1V27SttsRAi48AJ9bBMj8fMpcr0eOSVF+uFYiOxv3tACgqjzf SB33htk6v/2DNxJTz9D5S3U= =hi3Q -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any hope to have things requested by NVidia in FreeBSD-7?
Yuri wrote: I read long time ago that the reason that NVidia can't have their driver on 64-bit platform is that FreeBSD kernel lacks some functionality. Is this functionality present in 7.0? Or when to expect this to be done? I have NVidia card but still run 32-bit system because of lack of driver. Yuri Hello, This discussion gets over and over again actually, no the required support is not yet there. There is a wiki page which denotes what is required to get this going. http://wiki.freebsd.org/NvidiaFeatureRequests If you desperately need this, then consider funding someone (this has popped up before, it's interesting to arrange something like this because you need a trustable intermediating party that can arrange this, the FreeBSD Foundation is currently not able to do so as far as I can recall); who will do the work for you or do it yourself. There is currently no other way to get the support you want. Thanks, remko -- /\ Best regards, | [EMAIL PROTECTED] \ / Remko Lodder | [EMAIL PROTECTED] Xhttp://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any hope to have things requested by NVidia in FreeBSD-7?
On Nov 16, 2007 2:16 PM, Remko Lodder [EMAIL PROTECTED] wrote: Yuri wrote: I read long time ago that the reason that NVidia can't have their driver on 64-bit platform is that FreeBSD kernel lacks some functionality. Is this functionality present in 7.0? Or when to expect this to be done? I have NVidia card but still run 32-bit system because of lack of driver. Yuri Hello, This discussion gets over and over again actually, no the required support is not yet there. There is a wiki page which denotes what is required to get this going. http://wiki.freebsd.org/NvidiaFeatureRequests If you desperately need this, then consider funding someone (this has popped up before, it's interesting to arrange something like this because you need a trustable intermediating party that can arrange this, the FreeBSD Foundation is currently not able to do so as far as I can recall); who will do the work for you or do it yourself. There is currently no other way to get the support you want. Thanks, remko Remko - relax :) The wiki isn't really an obvious place for people to look. If we don't already we should have a page on popular hardware with support issues. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any hope to have things requested by NVidia in FreeBSD-7?
Kip Macy wrote: On Nov 16, 2007 2:16 PM, Remko Lodder [EMAIL PROTECTED] wrote: Yuri wrote: I read long time ago that the reason that NVidia can't have their driver on 64-bit platform is that FreeBSD kernel lacks some functionality. Is this functionality present in 7.0? Or when to expect this to be done? I have NVidia card but still run 32-bit system because of lack of driver. Yuri Hello, This discussion gets over and over again actually, no the required support is not yet there. There is a wiki page which denotes what is required to get this going. http://wiki.freebsd.org/NvidiaFeatureRequests If you desperately need this, then consider funding someone (this has popped up before, it's interesting to arrange something like this because you need a trustable intermediating party that can arrange this, the FreeBSD Foundation is currently not able to do so as far as I can recall); who will do the work for you or do it yourself. There is currently no other way to get the support you want. Thanks, remko Remko - relax :) The wiki isn't really an obvious place for people to look. If we don't already we should have a page on popular hardware with support issues. -Kip Can't there be something added such as an easy to search for FAQ so this topic doesn't come up 2-7 times per month? I know people should use a search engine and search for the information first, but people seem extremely lazy and always ask current@, hackers@, and questions@, amongst other lists I'm sure.. Thanks, -Garrett PS Please CC me if replying on chat@, as I'm not subscribed to that list. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any hope to have things requested by NVidia in FreeBSD-7?
Yuri wrote: I read long time ago that the reason that NVidia can't have their driver on 64-bit platform is that FreeBSD kernel lacks some functionality. Is this functionality present in 7.0? Or when to expect this to be done? I have NVidia card but still run 32-bit system because of lack of driver. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] You are correct and, no, this functionality will not be available on 7.0, though someone is working on the problem. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any hope to have things requested by NVidia in FreeBSD-7?
Can't there be something added such as an easy to search for FAQ so this topic doesn't come up 2-7 times per month? I know people should use a search engine and search for the information first, but people seem extremely lazy and always ask current@, hackers@, and questions@, amongst other lists I'm sure.. Thanks, -Garrett Add the printout to nvidia-driver port telling the address of this Wiki-page. All people who use NVidia have to go there to update the driver so they will see the URL. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any hope to have things requested by NVidia in FreeBSD-7?
Can't there be something added such as an easy to search for FAQ so this topic doesn't come up 2-7 times per month? I know people should use a search engine and search for the information first, but people seem extremely lazy and always ask current@, hackers@, and questions@, amongst other lists I'm sure.. Thanks, -Garrett PS Please CC me if replying on chat@, as I'm not subscribed to that list. BTW googling nvidia freebsd driver amd64 doesn't show this Wiki-page on the first 3 google-pages. This means that it's not named properly. 'Feature requests' isn't what most people would search for. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
