differences in USB support between FreeBSD 4.x and 5.x ?
[I sent the same message to [EMAIL PROTECTED], but since that list seems not very active, I am asking here too] Hi all, the subject says it all. I am considering using FreeBSD for a robotics project, and I am thinking of using 4.x for stability. But, since we will probably use USB a lot, I am wondering if maybe 5.x is a better choice. Any ideas, besides the compare the USB source between 4.x and 5.x suggestion? ;-) thanks marco ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
How to use functions from libs in /usr/local/lib in pam?
I'm trying to write pam module, which uses libs from /usr/local/lib (lber
and lsap). What should i put in Makefile in order to link module with this
libs?
LIBLDAP= /usr/local/lib/ldap.a
LDADD+= -L/usr/local/lib -lldap
LDFLAGS += -L/usr/local/lib -lldap
DPADD= ${LIBCRYPT} ${LIBLDAP}
doesn't help.
Thanks in advance.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.8 panic ffs_clusteralloc: map mismatch [SOLVED]
On Wed, Jul 16, 2003 at 05:57:44AM -0700, Avleen Vig wrote: I have been experiencing several ffs_clusteralloc: map mismatch kernel panics (always while heavy r/w activity on ad0). PC in question has SuperMicro P3TDL3 motherboard, 2 ide + 1 scsi HDD and 4 nics (full dmesg kernel config attached). Andrew, I spend about two to three years fighting with a system trying to figure out what was wrong, and why these errors were caused. I got the very same crashes you're seeing now. I'm sure others are too, and I think this reply would be useful for the archives. It seems that this panic was a result of filesystem corruption, which was caused by hw.ata.wc=1 on ServerWorks ROSB4 ATA33 controller and ST320414A HDD. After setting up hw.ata.wc=0 in /boot/loader.conf problems are all gone. -- Avleen Vig Say no to cheese-eating surrender-monkeys Systems AdminFast, Good, Cheap. Pick any two. www.silverwraith.com Move BSD. For great justice! Andrew. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to use functions from libs in /usr/local/lib in pam?
On Mon, Jul 21, 2003 at 04:42:12AM -0400, Ilmar S. Habibulin wrote:
I'm trying to write pam module, which uses libs from /usr/local/lib (lber
and lsap). What should i put in Makefile in order to link module with this
libs?
LIBLDAP= /usr/local/lib/ldap.a
LDADD+= -L/usr/local/lib -lldap
LDFLAGS += -L/usr/local/lib -lldap
DPADD= ${LIBCRYPT} ${LIBLDAP}
doesn't help.
The library should be named /usr/local/lib/libldap.a at the minimum,
to make -lldap work. Also, -L should be taken out of LDADD, and be
put only in LDFLAGS, so it should look like this:
LIBLDAP=/usr/local/lib/libldap.a
DPADD= ${LIBCRYPT} ${LIBLDAP}
LDADD= -lcrypt -lldap
LDFLAGS=-L/usr/local/lib
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: differences in USB support between FreeBSD 4.x and 5.x ?
On Mon, Jul 21, 2003 at 09:18:42AM +0200, Marco Molteni wrote: [I sent the same message to [EMAIL PROTECTED], but since that list seems not very active, I am asking here too] Hi all, the subject says it all. I am considering using FreeBSD for a robotics project, and I am thinking of using 4.x for stability. But, since we will probably use USB a lot, I am wondering if maybe 5.x is a better choice. I believe 4.x has all you need for your project. If you really find a problem then the missing part can be MFC'ed. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Communications kernel - userland
On Sat, 19 Jul 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Marc Ramirez [EMAIL PROTECTED] writes: : I have a device driver that needs to make requests for data from a : userland daemon. What's the preferred method for doing this in 4.8R and : 5.1R? I'm assuming the answer is Unix-domain sockets... what's wrong with a simple read channel? Nothing except that this is my first real foray into non-trivial kernel programming. :) Marc. why complicate things by bringing sockets into it? Warner -- Marc Ramirez Blue Circle Software Corporation 513-688-1070 (main) 513-382-1270 (direct) www.bluecirclesoft.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Communications kernel - userland
On Fri, 18 Jul 2003, Terry Lambert wrote: Marc Ramirez wrote: I asked this in -questions, but got no response; sorry for the repost. I have a device driver that needs to make requests for data from a userland daemon. What's the preferred method for doing this in 4.8R and 5.1R? I'm assuming the answer is Unix-domain sockets... It depends on the application. In most cases these are set up as request/response protocols. In that case, the best method is to ise an ioctl() or fcntl() (which you use depends on what in the kernel is talking to userland), and then returning to user space with the request. The userland then makes another call back down with the response, and the next wait-for-request. This saves you fully 50% of the protection domain crossing system calls from an ordinary callback, and it saves you 300% of the protection domain crossings of what you would need for a pipe/FIFO/unix-domain-socket. I understand. Thanks! E.g.: userkernel -- REQ1 make_req() sleep_waiting_for_available() ioctl(fd, MY_GETREQ, req) sleep_waiting_for_req() copyout() sleep_waiting_for_rsp() ioctl(fd, MY_RSPREQ, req) sleep_waiting_for_req() copyin() ... REQ2 make_req() copyout() sleep_waiting_for_rsp() ioctl(fd, MY_RSPREQ, req) sleep_waiting_for_req() copyin() ... ... -- Terry -- Marc Ramirez Blue Circle Software Corporation 513-688-1070 (main) 513-382-1270 (direct) www.bluecirclesoft.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
PAE correctness
I should be most grateful if someone reviews the attached code fragment
and let me know how to do the right thing for PAE whilst remaining
machine-independent.
My previous version of this code was written after reading the pre-busdma'd
bktr(4) driver, which used pmap_kenter() - bad puppy!
Should I even be using pmap_map() in this case? This does make the
assumption that the cardbus/pccard drivers take care of pushing the
memory window into PCI visibility, and that the PCI regions can be
mapped into the 'real' memory address space.
I should note I also peeked at sparc64_bus_mem_map() this morning
for pointers.
Love and hugs,
BMS
...
struct pcmem_softc {
...
/* common memory mapping descriptors */
vm_paddr_t sc_cm_base;
vm_paddr_t sc_cm_size;
vm_offset_t sc_cm_kva_base;
vm_size_tsc_cm_kva_size;
...
};
...
/*
* pcmem_phys_map():
*
* Map the common memory window of the PCMCIA memory card in an
* architecture-independent and SMP coherent manner. Record the
* addresses used within the card's soft-state structure for
* later use by pcmem_phys_unmap().
*
* The pccard code does not map the window for us, therefore
* this code is necessary.
*
* Returns the first mapped virtual address of the card's common
* memory, or 0 to indicate failure.
*
* XXX needs address arithmetic review for PAE
*/
static vm_offset_t
pcmem_phys_map(struct pcmem_softc *sc)
{
vm_paddr_t pa, off, psize;
vm_offset_t va;
vm_size_tvsize;
/* clip all address ranges to within page boundaries */
pa = trunc_page(sc-sc_cm_base);
psize = round_page(sc-sc_cm_size);
vsize = (vm_size_t) psize;
off = sc-sc_cm_base - pa;
/* reserve a non-pageable memory range within the kva. */
va = kmem_alloc_nofault(kernel_map, vsize);
if (va == (vm_offset_t) 0)
return (0);
va = pmap_map(va, pa, pa + psize, VM_PROT_READ);
if (va == (vm_offset_t) 0) {
kmem_free(kernel_map, va, vsize);
return (0);
}
sc-sc_cm_kva_size = vsize;
sc-sc_cm_kva_base = va;
return (va + off);
}
/*
* pcmem_phys_unmap():
*
* Unmap the common memory window of the PCMCIA memory card in an
* architecture-independent and SMP coherent manner.
*/
static void
pcmem_phys_unmap(struct pcmem_softc *sc)
{
pmap_remove(kernel_pmap, sc-sc_cm_kva_base, sc-sc_cm_kva_size);
kmem_free(kernel_map, sc-sc_cm_kva_base, sc-sc_cm_kva_size);
sc-sc_cm_kva_base = sc-sc_cm_kva_size = 0;
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Communications kernel - userland
On Sat, 19 Jul 2003, Pawel Jakub Dawidek wrote: On Fri, Jul 18, 2003 at 03:47:05PM -0400, Marc Ramirez wrote: + I have a remote datastore that I want to present as a filesystem. There + are two parts to this: fetching raw data over the network, and doing some + processing on the data. For purposes of maintainability, I'd like to do + as little of this as possible inside the kernel, so I've currently got a + daemon to fetch and process the data, and then pipes it over a socket to + the kernel FS layer. Your choices are: - device, - sysctl, - syscall. You need to think about what you exactly need and which options will be the best. Creating new syscall isn't good idea, creating device is more complicated than sysctl, but of course it's up to you and your needs. Okay, thanks. Syscall seems completely counter-intuitive for my needs, anyway. Marc. -- Marc Ramirez Blue Circle Software Corporation 513-688-1070 (main) 513-382-1270 (direct) www.bluecirclesoft.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Communications kernel - userland
Cool. Thanks, everyone! Messrs. Watson and Lambert have convinced me to go the pseudo-device route. I think that's really going to clean up a lot of the code. I'm so excited! Thanks! Marc. On Sun, 20 Jul 2003, Robert Watson wrote: On Sat, 19 Jul 2003, Pawel Jakub Dawidek wrote: Your choices are: - device, - sysctl, - syscall. There are actually a few other more obscure ways to push information from the kernel to userspace, depending on what you want to accomplish. Write directly to a file from the kernel. ktrace, system accounting, and ktr with alq all stream data directly to a file provided by an authorized user process. quotas and UFS1 extended attribute data are also written directly to a file. On other operating systems, audit implementations frequently take the same approach -- when the goal is long term storage of data in a user-accessible form, but you don't want to stream it through a user process live, this is usually the preference. Typically, when taking this approach, a special system call is used to notify the kernel of the target file to write to -- the file is created by the user process with appropriate protections. Often, but not always, the system call is non-blocking and simply returns once the file is hooked up as a target, and continues until another system call cancels delivery, or switches it to a new target. Stream it through a device node. If you need only one or a small number of processes to listen for events from the kernel, a common approach is a pseudo-device that acts like a file. For example, syslogd listens on /dev/klog for log events from the kernel; some audit implementations also take this approach. Our devd, usbd, and others similarly listen for system events that are exposed to user processes as data on a blocking pseudo-device. One nice thing about this approach is that you can combine it with select(), kqueue(), et al, to do centralized event management in the application. BPF also does this. Both Arla and Coda take this approach for LPC'ing to userspace to request events as a result of VFS operations by processes. Expose it using a special socket type. We expose routing data and network stack administrative controls as special reads, writes, and ioctls on various socket types. I'm not a big fan of this approach, as it special cases a lot of bits, and requires you to get caught up in socket semantics. However, one advantage of this approach is it makes the notion of multicast of events to multiple listeners easier to deal with, since each socket endpoint has automatic message buffering. There are some other odd cases in use as well. The NFS locking code opens a specially named fifo (/var/run/lock) and writes messages to it, which are picked up by rpc.lockd. The lock daemon pushes events back into the kernel using a special system call. I don't really like this approach, as it has some odd semantics -- especially since it reopens the fifo for each operation, and there are credential/ file system namespace inconsistencies. Of these approaches, my favorite are writing directly to a file, and using a psuedo-device, depending on the requirements. They have fairly well-defined security semantics (especially if you properly cache the open-time credentials in the file case). I don't really like the Fifo case as it has to re-look-up the fifo each time, and has some odd blocking semantics. Sockets, as I said, involve a lot of special casing, so unless you're already dealing with network code, you probably don't want to drag it into the mix. If you're creating big new infrastructure for a feature, I suppose you could also hook it up as a first class object at the file descriptor level, in the style of kqueue. If it's relatively minor event data, you could hook up a new kqueue event type. You could also just use a special-purpose system call or sysctl if you don't mind a lot of context switching and lack of buffering. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories -- Marc Ramirez Blue Circle Software Corporation 513-688-1070 (main) 513-382-1270 (direct) www.bluecirclesoft.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible issue with in-kernel ELF loader.
:It turns out that the kernel's internal ELF loader is misinterpreting :an ABS symbol (i.e. set with .SET in assembly) whos value is 0 as being :'not found', and once that is fixed it was also confusing the absolute :symbol with a COMMON symbol. : :Thanks for the pointer. FWIW, We use -fno-common on 5.x to avoid common :symbols even existing in the first place. There were a few missing :externs that this turned up. : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Hmm. Though you seem to override it for the linux and svr4 modules. It's a little too hackish for my tastes but I'll keep it in mind. There's something to be said for being able to clean up those kinds of declarations. -Matt Matthew Dillon [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: differences in USB support between FreeBSD 4.x and 5.x ?
In message: [EMAIL PROTECTED] Marco Molteni [EMAIL PROTECTED] writes: : Any ideas, besides the compare the USB source between 4.x and 5.x : suggestion? ;-) USB hot plugging in 4.x sucks really bad. it is tolerably ok in 5.x for non-weird devices. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Correct way to call execve?
In a message written on Mon, Jul 21, 2003 at 08:53:53AM -0700, Tim Kientzle wrote:
Actually, this example passes -Wall if you declare
execargv as simply char *[]. However, I'm looking
for something that passes gcc -Wwrite-strings, which this
example does not.
% cat exec.c
#include unistd.h
#include paths.h
int main(int argc, char *const argv[], char *const envp[]) {
char *execargv[2];
execargv[0] = (char *)_PATH_BSHELL;
execargv[1] = (char *)NULL;
execve(_PATH_BSHELL,execargv,envp);
return 0;
}
% cc -Wwrite-strings exec.c
% cc -Wall exec.c
Looks good to me.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp0.pgp
Description: PGP signature
Re: Correct way to call execve?
On Mon, Jul 21, 2003 at 12:57:35PM -0400, Leo Bicknell wrote:
In a message written on Mon, Jul 21, 2003 at 08:53:53AM -0700, Tim Kientzle wrote:
Actually, this example passes -Wall if you declare
execargv as simply char *[]. However, I'm looking
for something that passes gcc -Wwrite-strings, which this
example does not.
% cat exec.c
#include unistd.h
#include paths.h
int main(int argc, char *const argv[], char *const envp[]) {
char *execargv[2];
execargv[0] = (char *)_PATH_BSHELL;
execargv[1] = (char *)NULL;
execve(_PATH_BSHELL,execargv,envp);
return 0;
}
% cc -Wwrite-strings exec.c
% cc -Wall exec.c
Looks good to me.
Try cc -Wwrite-strings -Wcast-qual exec.c.
You cannot simply cast away a const.
--
Chad David[EMAIL PROTECTED]
www.FreeBSD.org [EMAIL PROTECTED]
ISSci Inc.Calgary, Alberta Canada
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Correct way to call execve?
In a message written on Mon, Jul 21, 2003 at 11:15:38AM -0600, Chad David wrote:
Try cc -Wwrite-strings -Wcast-qual exec.c.
You cannot simply cast away a const.
Grumble, will someone give me all the warnings you want turned on so I
can work around all of them? :)
% cat exec.c
#include unistd.h
#include paths.h
#include string.h
int main(int argc, char *const argv[], char *const envp[]) {
char *const execargv[] = { strdup(_PATH_BSHELL), strdup(NULL) };
execve(_PATH_BSHELL,execargv,envp);
return 0;
}
% cc -Wwrite-strings -Wcast-qual exec.c
% cc -Wall exec.c
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp0.pgp
Description: PGP signature
Re: Correct way to call execve?
On Mon, Jul 21, 2003 at 01:23:21PM -0400, Leo Bicknell wrote:
In a message written on Mon, Jul 21, 2003 at 11:15:38AM -0600, Chad David wrote:
Try cc -Wwrite-strings -Wcast-qual exec.c.
You cannot simply cast away a const.
Grumble, will someone give me all the warnings you want turned on so I
can work around all of them? :)
% cat exec.c
#include unistd.h
#include paths.h
#include string.h
int main(int argc, char *const argv[], char *const envp[]) {
char *const execargv[] = { strdup(_PATH_BSHELL), strdup(NULL) };
execve(_PATH_BSHELL,execargv,envp);
return 0;
}
% cc -Wwrite-strings -Wcast-qual exec.c
% cc -Wall exec.c
You can/should probably skip the strdup(NULL), or ensure V in malloc.conf :).
I assumed it was obvious that you could copy the data, but I believe
the intent of the original question was to find an alternative. As
far as I know there isn't one. A const is a const, except in C++.
--
Chad David[EMAIL PROTECTED]
www.FreeBSD.org [EMAIL PROTECTED]
ISSci Inc.Calgary, Alberta Canada
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Communications kernel - userland
Robert Watson wrote: Of these approaches, my favorite are writing directly to a file, and using a psuedo-device, depending on the requirements. They have fairly well-defined security semantics (especially if you properly cache the open-time credentials in the file case). I don't really like the Fifo case as it has to re-look-up the fifo each time, and has some odd blocking semantics. Sockets, as I said, involve a lot of special casing, so unless you're already dealing with network code, you probably don't want to drag it into the mix. If you're creating big new infrastructure for a feature, I suppose you could also hook it up as a first class object at the file descriptor level, in the style of kqueue. If it's relatively minor event data, you could hook up a new kqueue event type. You could also just use a special-purpose system call or sysctl if you don't mind a lot of context switching and lack of buffering. I like setting the PG_G bit on the page involved, which maps it into the address space of all processes. 8-). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: differences in USB support between FreeBSD 4.x and 5.x ?
In article [EMAIL PROTECTED] you wrote: In message: [EMAIL PROTECTED] Marco Molteni [EMAIL PROTECTED] writes: : Any ideas, besides the compare the USB source between 4.x and 5.x : suggestion? ;-) USB hot plugging in 4.x sucks really bad. it is tolerably ok in 5.x for non-weird devices. 5.x seems to have much better support for USB 2.0 as well. I have a SanDisk 2.0 USB compact flash reader that just works with 5.1 release. So far no amount of kernel hacking has made it work with 4.8. Unfortunetly for me I need it to work under 4.8. )-: Larry -- Larry Baird| http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: [EMAIL PROTECTED] | TEL 407-380-0220, FAX 407-380-6080 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VM problem...
On Mon, Jul 21, 2003 at 01:57:59AM +0200, Pawel Jakub Dawidek wrote: + So as you can see I'm listing every entry that isn't writable. + This function is called when process is killed by kernel with SIGBUS. + It shows me that only this region isn't writable: + + ENTRY:PID: 0-0xbfc0 (0:0) Of course it isn't it. I've changed all map entries protection to VM_PROT_ALL and now on SIGBUS (in trapsignal()) every listed entry got protection = VM_PROT_ALL and max_protection = VM_PROT_ALL. So what the hell is going on here?:S I'm not a VM expert so please help me to track this down. I'm trying real hard to made this by myself for a week now. Is there posibility that there is some map entry that isn't on process p-p_vmspace-vm_map? Maybe some shared entry not connected with his map, but which should be accessable for this process? If trap is generated, because of illegal access nothing is changed with map entries before trapsignal() is called? I'm really confused, so if someone could find few minutes, hour or short day:) to help me track this down, I'll be really grateful. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Communications kernel - userland
On Mon, 21 Jul 2003, Terry Lambert wrote: Robert Watson wrote: Of these approaches, my favorite are writing directly to a file, and using a psuedo-device, depending on the requirements. They have fairly well-defined security semantics (especially if you properly cache the open-time credentials in the file case). I don't really like the Fifo case as it has to re-look-up the fifo each time, and has some odd blocking semantics. Sockets, as I said, involve a lot of special casing, so unless you're already dealing with network code, you probably don't want to drag it into the mix. If you're creating big new infrastructure for a feature, I suppose you could also hook it up as a first class object at the file descriptor level, in the style of kqueue. If it's relatively minor event data, you could hook up a new kqueue event type. You could also just use a special-purpose system call or sysctl if you don't mind a lot of context switching and lack of buffering. I like setting the PG_G bit on the page involved, which maps it into the address space of all processes. 8-). For one of our research projects, here at NAI, we did a fair amount of userland network code prototyping. We started out with IPDIVERT, then pushed down to BPF using a partial network stack in userspace. We've found it's a lot easier on competent network developers who are unfamiliar with the FreeBSD kernel code, not to mention easier on debugging. We never got so far on that project as to do shared memory between the kernel and userspace, but I know that that's been done by at least a couple of companies at various points to reduce copying and context switch costs for userspace test frameworks. One of the things I'd really like to see if some decent throw packets between kernel and userspace primitive bits, such that the kernel has a useful and logical way to expose buffer data into directly mapped user pages, and an appropriate notification and management system to reuse memory, etc. Something that looks a bit like the relationship between kernel device drivers and devices when it comes to DMA management. Do you know if any such framework exists? (Specifically targetted at exposing network packets...) (Ideally not requiring privilege in the user process, nor involving nasty integrity or confidentiality problems :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Correct way to call execve?
Chad David wrote: I assumed it was obvious that you could copy the data, but I believe the intent of the original question was to find an alternative. As far as I know there isn't one. A const is a const, except in C++. Yes, the intent was to find a way to avoid copying the data. I was hoping that someone knew a standard way to say yes, I really do mean to cast away that const, akin to C++ const_cast. As far as I can tell, the POSIX-mandated declaration of execvp is simply wrong. (SUSv3 even has a comment that essentially admits this fact and then vainly tries to rationalize it. sigh) Basically, there is no const-correct way to invoke execvp using literal strings for argv except to copy the strings. In particular, the FreeBSD implementation of popen(), for example, cannot be compiled with strict warnings. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Correct way to call execve?
In a message written on Mon, Jul 21, 2003 at 11:24:43AM -0700, Tim Kientzle wrote: I was hoping that someone knew a standard way to say yes, I really do mean to cast away that const, akin to C++ const_cast. I'm missing something here. You can do that, but you can't do that with say -Wcast-qual, which is basically a flag to say I don't care what the code says, tell me about those situations. Basically, there is no const-correct way to invoke execvp using literal strings for argv except to copy the strings. In particular, the FreeBSD implementation of popen(), for example, cannot be compiled with strict warnings. Depends on what you call correct. cc compiles it quietly. cc -Wall compiles quietly. cc -ansi compiles quietly. cc -pedantic compiles quietly. Sure, there are options you can turn on that show you these /warnings/, but that doesn't mean those options are actually showing you problems with your code. Just because you can run cc -nostdlib doesn't mean all code that fails to compile is broken, it means you used the wrong option. Similarly, if you do things in your program that require constants to not be, then turning on an option to warn you about that seems a bit backwards as well. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Correct way to call execve?
You know, my own thinking made me figure this one out:
% cat exec.c
#include unistd.h
#include paths.h
#include string.h
int main(int argc, char *const argv[], char *const envp[]) {
char *const execargv[] = { _PATH_BSHELL, NULL };
execve(_PATH_BSHELL,execargv,NULL);
return 0;
}
% cc -fwritable-strings -Wcast-qual -Wwrite-strings exec.c
%
There you go. By default strings are read-only, and indeed smart
compilers use that to compress them and do other nifty tricks. However,
in this case you really want a string to be char *, eg writable.
So, tell the compiler to do that with -fwritable-strings, poof,
strings are now char *, the cast away the cost problem goes away,
-Wcast-qual works fine.
It always seemed to me a lot of things included -fwritable-strings for
no good reason, maybe this is part of the reason. :)
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp0.pgp
Description: PGP signature
Re: Communications kernel - userland
On Mon, Jul 21, 2003 at 02:20:40PM -0400, Robert Watson wrote: + For one of our research projects, here at NAI, we did a fair amount of + userland network code prototyping. We started out with IPDIVERT, then + pushed down to BPF using a partial network stack in userspace. We've + found it's a lot easier on competent network developers who are unfamiliar + with the FreeBSD kernel code, not to mention easier on debugging. We + never got so far on that project as to do shared memory between the kernel + and userspace, but I know that that's been done by at least a couple of + companies at various points to reduce copying and context switch costs for + userspace test frameworks. One of the things I'd really like to see if + some decent throw packets between kernel and userspace primitive bits, + such that the kernel has a useful and logical way to expose buffer data + into directly mapped user pages, and an appropriate notification and + management system to reuse memory, etc. Something that looks a bit like + the relationship between kernel device drivers and devices when it comes + to DMA management. Do you know if any such framework exists? + (Specifically targetted at exposing network packets...) (Ideally not + requiring privilege in the user process, nor involving nasty integrity or + confidentiality problems :-) It will be cool to have something like this: mark(vm_map_t map, vm_offset_t start, vm_offset_t end); unmark(vm_map_t map, vm_offset_t start, vm_offset_t end); It will be used instead of copyin()/copyout() functions. For example syscall is marking some range with mark() function. For now on this range isn't accessable from userland. If process will try to write to this page, page is copied (copy-on-write). If this page will be modified by kernel it will be marked as MODIFIED. Now when syscall will call unmark() on this range we could get two scenarious: 1. Page is marked as MODIFIED (by kernel) so userland copy of this page (if it exists of course) is destroyed and this page will be putted in its place. This is replacement for copyin() and then copyout() or just copyout().. 2. Page isn't marked as MODIFIED, so kernel version of page is destroyed (is there is userland version). This is replacement for just copyin(). There could be other ways. Thread/process could be locked if it is trying to access memory marked with mark() function. And this, I think, don't hit performance, because this happends really rarely. So maybe it is better to lock thread for a moment instead of doplicating page, but I don't think so. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: VM problem...
Hmm. Is the VM object properly sized? Any attempt to fault-in data beyond a VM object's EOF, regardless of how you set the map_entry permissions, will seg fault or bus fault. -Matt Matthew Dillon [EMAIL PROTECTED] : : :--LZvS9be/3tNcYl/X :Content-Type: text/plain; charset=iso-8859-2 :Content-Disposition: inline :Content-Transfer-Encoding: quoted-printable : :On Mon, Jul 21, 2003 at 01:57:59AM +0200, Pawel Jakub Dawidek wrote: :+ So as you can see I'm listing every entry that isn't writable. :+ This function is called when process is killed by kernel with SIGBUS. :+ It shows me that only this region isn't writable: :+=20 :+ ENTRY:PID: 0-0xbfc0 (0:0) : :Of course it isn't it. I've changed all map entries protection to :VM_PROT_ALL and now on SIGBUS (in trapsignal()) every listed entry :got protection =3D VM_PROT_ALL and max_protection =3D VM_PROT_ALL. :So what the hell is going on here?:S : :I'm not a VM expert so please help me to track this down. I'm trying :real hard to made this by myself for a week now. : :Is there posibility that there is some map entry that isn't on process :p-p_vmspace-vm_map? Maybe some shared entry not connected with his :map, but which should be accessable for this process? : :If trap is generated, because of illegal access nothing is changed :with map entries before trapsignal() is called? : :I'm really confused, so if someone could find few minutes, hour or short :day:) to help me track this down, I'll be really grateful. : :--=20 :Pawel Jakub Dawidek [EMAIL PROTECTED] :UNIX Systems Programmer/Administrator http://garage.freebsd.pl :Am I Evil? Yes, I Am! http://cerber.sourceforge.net : :--LZvS9be/3tNcYl/X :Content-Type: application/pgp-signature :Content-Disposition: inline : :-BEGIN PGP SIGNATURE- :Version: GnuPG v1.0.7 (FreeBSD) : :iQCVAwUBPxwuXT/PhmMH/Mf1AQHDUwP+Pg+iws+uH4mYOrwRwrJdA/Jd9Qibofpx :cMmiW3jhc6kIMyNoYTzwpg/rL/3pwP+7iwSTX66DYtpjZPGD/OwHIB/c9IOWVzB7 :QiC1a7zN3ZywObWPIxCaxRkO+vHQWDNXQZGBGz8nuJzMa/HFvSB/DkgaxNy5BybT :7wfbv7cimJ4= :=/FGJ :-END PGP SIGNATURE- : :--LZvS9be/3tNcYl/X-- : ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VM problem...
On Mon, Jul 21, 2003 at 12:03:59PM -0700, Matthew Dillon wrote: + Hmm. Is the VM object properly sized? Any attempt to fault-in data + beyond a VM object's EOF, regardless of how you set the map_entry + permissions, will seg fault or bus fault. I'm allocationg memory with obreak() function (so vm_map_find() function is used to find space). But if I try to allocate size (and size is small), obreak() will allocate more memory. end = vm-vm_daddr + ctob(vm-vm_dsize); obreak(vm, end + size); vm_map_protect(vm-vm_map, end, end + size, VM_PROT_READ); And vm_map_protect() will create new map entry (it should, right?) with entry-start = end and entry-end = end + size. But what happend with those entries when execve() is called? Because process' map catched before execve() doesn't exists after execve() is called. So maybe those entries (with VM_PROT_READ) are reused somehow? THANKS! -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: VM problem...
: end =3D vm-vm_daddr + ctob(vm-vm_dsize); : obreak(vm, end + size); : vm_map_protect(vm-vm_map, end, end + size, VM_PROT_READ); : :And vm_map_protect() will create new map entry (it should, right?) :with entry-start =3D end and entry-end =3D end + size. : :But what happend with those entries when execve() is called? :Because process' map catched before execve() doesn't exists after :execve() is called. So maybe those entries (with VM_PROT_READ) are :reused somehow? : :THANKS! : :--=20 :Pawel Jakub Dawidek [EMAIL PROTECTED] Hmm. Well, when a process forks the vm_map_entry's fork along with it. The underlying VM objects remain shared but become copy-on-write. It sounds like whatever you are doing is messing up the user stack, and the program is bus-faulting when it can't write to the user stack. All sorts of things have to write to the user stack, including the signal trampoline code and even execve(). The fault address you reported earlier, 0xbfbffc20, is on the user stack. -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VM problem...
Hi Pawel, On Mon, Jul 21, 2003 at 09:16:22PM +0200, Pawel Jakub Dawidek wrote: I'm allocationg memory with obreak() function (so vm_map_find() function is used to find space). But if I try to allocate size (and size is small), obreak() will allocate more memory. You may find the vm_map and pmap documentation which I have just submitted to the project helpful for reference:- http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/54691 http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/54632 and ref: our online conversation about the vm_map_insert() semantics (and possible failure mode re: NULL vm_object argument for the user process case). Regards, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Communications kernel - userland
On Mon, 21 Jul 2003, Pawel Jakub Dawidek wrote: For example syscall is marking some range with mark() function. For now on this range isn't accessable from userland. If process will try to write to this page, page is copied (copy-on-write). If this page will be modified by kernel it will be marked as MODIFIED. Now when syscall will call unmark() on this range we could get two scenarious: 1. Page is marked as MODIFIED (by kernel) so userland copy of this page (if it exists of course) is destroyed and this page will be putted in its place. This is replacement for copyin() and then copyout() or just copyout().. 2. Page isn't marked as MODIFIED, so kernel version of page is destroyed (is there is userland version). This is replacement for just copyin(). There could be other ways. Thread/process could be locked if it is trying to access memory marked with mark() function. And this, I think, don't hit performance, because this happends really rarely. So maybe it is better to lock thread for a moment instead of doplicating page, but I don't think so. This sounds a bit like some of the IO Lite stuff -- moving to a page-centric model for IO interfaces to avoid copy operations, in many cases able to share pages between applications, buffer cache, network buffers, etc. Take a look at: http://www.cs.princeton.edu/~vivek/ For some details. Some of the benefits of this approach are captured in the common case through sendfile(), in practice, but it's definitely worth a read. I guess what I had in mind was something more network-specific, with interfaces optimized for memory mapped network packet streams. In the simplest case, something like memory-mapping the BPF buffer from kernel space to userspace, with some sort of simple stream synchronization so that the user application could notify the kernel as to when it could reuse bits of the buffer, but avoiding copy operations and lots of context switching. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VM problem...
On Mon, Jul 21, 2003 at 12:32:19PM -0700, Matthew Dillon wrote: + Hmm. Well, when a process forks the vm_map_entry's fork along with + it. The underlying VM objects remain shared but become copy-on-write. Yes, but I mean while execve(), not fork(). Before execve() is called map got for example 65 pages in its vm map. One of this page is marked as read-only. After execve() process vm map got only 2 pages. I susspect, that pages from before execve() are floating around. And this read-only pages also and maybe it can be reused for stack? If not, what happend with them? -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: complicated downgrade
Valentin Nechayev [EMAIL PROTECTED] writes: I need to downgrade a remote FreeBSD system from 5.1-release to 4.8-release remotely without any local help (except possible hitting Reset). Maybe if you tell us why you need to do this we can figure out a way for you to avoid doing it? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: differences in USB support between FreeBSD 4.x and 5.x ?
On Monday 21 July 2003 15:00, Bernd Walter wrote: On Mon, Jul 21, 2003 at 09:18:42AM +0200, Marco Molteni wrote: [I sent the same message to [EMAIL PROTECTED], but since that list seems not very active, I am asking here too] Hi all, the subject says it all. I am considering using FreeBSD for a robotics project, and I am thinking of using 4.x for stability. But, since we will probably use USB a lot, I am wondering if maybe 5.x is a better choice. I believe 4.x has all you need for your project. If you really find a problem then the missing part can be MFC'ed. Both 4.x and 5.x have a pointer-bug in the ugen-driver causing memory to be overwritten outside a buffer when using isochronous transfers. I have sent a PR about this (with patch) back in April. **(: HINT HINT :) ** ( pr kern/51186 : http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern%2F51186 ) thanks, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: differences in USB support between FreeBSD 4.x and 5.x ?
5.x seems to have much better support for USB 2.0 as well. I have a SanDisk 2.0 USB compact flash reader that just works with 5.1 release. So far no amount of kernel hacking has made it work with 4.8. Unfortunetly for me I need it to work under 4.8. )-: As a follow up to this problem report. The problem turned out to be the USB hub I was using on my 4.8 box. I would have sworn I tested without the hub last week when I first had problems. But alas I must have dreamed I made this test. All is well under 5.1 and 4.8 with my SanDisk USB 2.0 compact flash reader. (-: Larry -- Larry Baird| http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: [EMAIL PROTECTED] | TEL 407-380-0220, FAX 407-380-6080 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VM problem...
On Mon, Jul 21, 2003 at 08:51:19PM +0100, Bruce M Simpson wrote: Matt, Bruce, thanks! I've track it down. Yes, those read-only pages was reused. So now I'm putting them on list before syscall is called, and after syscall is executed I free memory for non-execve syscalls and mark entries from list as VM_PROT_ALL for execve(). I'll play in the future with vm_map_delete() maybe those pages are removable in safe way. But why memory allocator, that is responsible for finding pages for stack don't check their permissions? -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Where / how to begin the FreeBSD development journey?
I've recently setup and started using Free-BSD 5.1 as my desktop at home and was looking to find more information about getting started in contributing to the Free-BSD project. What piqued my interest is the well organised clean Free-BSD kernel, and the vast wealth of documentation on using the system. Also, the general attitude of the Free-BSD community seems to be far more mature than that of many other operating systems projects that seem to be appearing all over lately. While I am no master of the trade so to speak, I have seen lots of code over the last 10 years or so, and reading the Free-BSD kernel code is quite pleasant and enjoyable in comparison. The responsiveness and stability of Free-BSD 5.1 on my system have convinced me enough that I've switched my personal development desktop and email to Free-BSD 5.1, it really is that wonderful. Now before anyone floats away from all the hot air I've blown, I was wondering if there were any other recommended pieces of reading material that might be helpful in better understanding Free-BSD's architecture and design. I am aware of Tannenbaum's books, and I also own a few Linux Kernel books as well. As well, I have read through most of the documentation already (certainly all that was available in the installer), and did not find any specific mentions of how one should begin to familiarise themselves with FreeBSD's internals and so forth. I did however find some recommendations to read 'The Design and Implementation of the 4.4 BSD Operating System', which I recently obtained and have begun. I did peruse the bugs list at the FreeBSD web site curious as to what the current outstanding issue list was, and felt compelled to see if there was anything left open that I might put my hand to and felt a bit overwhelmed. I noticed that there are over 2,000 some entries with some dating as far back as 1996. So, I wasn't exactly sure where one would begin there either. An acquaintance of mine had suggested that I should involve myself with the newly founded DragonFly BSD project. But, I felt that I would rather start here first. So where or how does one begin the journey? -- Shawn [EMAIL PROTECTED] http://drevil.warpcore.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where / how to begin the FreeBSD development journey?
On 21 Jul 2003 22:30:39 -0500, Shawn [EMAIL PROTECTED] wrote: I've recently setup and started using Free-BSD 5.1 as my desktop at home and was looking to find more information about getting started in contributing to the Free-BSD project. What piqued my interest is the well organised clean Free-BSD kernel, and the vast wealth of documentation on using the system. Also, the general attitude of the Free-BSD community seems to be far more mature than that of many other operating systems projects that seem to be appearing all over lately. While I am no master of the trade so to speak, I have seen lots of code over the last 10 years or so, and reading the Free-BSD kernel code is quite pleasant and enjoyable in comparison. The responsiveness and stability of Free-BSD 5.1 on my system have convinced me enough that I've switched my personal development desktop and email to Free-BSD 5.1, it really is that wonderful. Now before anyone floats away from all the hot air I've blown, I was wondering if there were any other recommended pieces of reading material that might be helpful in better understanding Free-BSD's architecture and design. I am aware of Tannenbaum's books, and I also own a few Linux Kernel books as well. As well, I have read through most of the documentation already (certainly all that was available in the installer), and did not find any specific mentions of how one should begin to familiarise themselves with FreeBSD's internals and so forth. I did however find some recommendations to read 'The Design and Implementation of the 4.4 BSD Operating System', which I recently obtained and have begun. I did peruse the bugs list at the FreeBSD web site curious as to what the current outstanding issue list was, and felt compelled to see if there was anything left open that I might put my hand to and felt a bit overwhelmed. I noticed that there are over 2,000 some entries with some dating as far back as 1996. So, I wasn't exactly sure where one would begin there either. An acquaintance of mine had suggested that I should involve myself with the newly founded DragonFly BSD project. But, I felt that I would rather start here first. So where or how does one begin the journey? Is this http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- handbook/ what you are looking for? Also, you can try to check http://www.freebsd.org/docs.html .. Cheers, Mezz -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where / how to begin the FreeBSD development journey?
On Mon, 2003-07-21 at 22:46, Jeremy Messenger wrote: Is this http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- handbook/ what you are looking for? Also, you can try to check http://www.freebsd.org/docs.html .. Thank you! I can't believe I missed that. I swear I looked all around the site, even in the section you mention. I read all of the normal handbook, but hadn't spotted that one. Again, I thank you! -- Shawn [EMAIL PROTECTED] http://drevil.warpcore.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
