Re: Request for swapcontext and getcontext to be ported to our libc
Petr, Based on information scattered about the Internet, as well as what the FreeBSD folks have done, it appears that powerdns-recursor requires gcc-3.4.6 to compile properly. This is a problem as DFly's native gcc is 3.4.5 and the pkgsrc version of 3.4.6 does not support DFly. To do this right, we will need DFly to support the 3.4.6 compiler before we can support this package. Regards, -- Matt Emmerton > > I see. > > What about getting someone to get powerdns-recusor compiling and running? > > > > Once that is done we shall arrange for your payment. > > > > Petr > > > > > > Matt Emmerton wrote: > > >> Hey, > > >> Any progress on the fully libc *context functions? > > >> > > > > > > I've toyed with it a bit, but there are some issues I'm not sure how to > > > solve (such as accessing curthread -- a kernel construct -- from > userland). > > > I would welcome discussion with the person who suggested it (corecode?). > > > > > > Also, I felt it pertinent to focus on the quick-start FreeBSD port to > get it > > > into the 1.8-release. > > > > > > -- > > > Matt Emmerton > > > > > > > > >
Re: Request for swapcontext and getcontext to be ported to our libc
I think we're debating whether to "do it right" or "do it now". Tuesday is a long way off yet :) -- Matt Emmerton > So is the current context code going into cvs HEAD or whats happening? > > Petr > > Simon 'corecode' Schubert wrote: > > Matthew Dillon wrote: > >> The answer is: yes, it is possible. There is no reason why the > >> signal mask (and signal pending bitmap) couldn't be stored in user > >> memory, allowing the userland threading system to swap out the mask > >> without entering the kernel. > > > > I absolutely agree. I am thinking of a special page mapped in kernel > > and userspace memory, where things like signal mask and pending (per > > thread) are located, and maybe also a timecounter, pid, etc. > > > >> So I think there is a very good argument for making the current > >> release > >> implementation do these calls in libc and not as system calls, and > >> initially have libc just get the signal mask with a system call, > >> then > >> at some later date add the feature sthat allow the userland context > >> routines to run fully without having to make any system calls at > >> all. > > > > If Matt Emmerton finds the time to implement it, I am all for it. > > Having these functions as syscalls seems wrong in my eyes. > > > > cheers > > simon > > >
Re: Request for swapcontext and getcontext to be ported to our libc
: :So is the current context code going into cvs HEAD or whats happening? : :Petr I'm going to let the discussion continue for another day or two but I will note that Matt is the person doing the work so it depends on how much time he has available to do the libc version prior to the release (assuming he agrees with the assessment that it is better to do the libc version for the release then the syscall version). -Matt
Re: Request for swapcontext and getcontext to be ported to our libc
So is the current context code going into cvs HEAD or whats happening? Petr Simon 'corecode' Schubert wrote: Matthew Dillon wrote: The answer is: yes, it is possible. There is no reason why the signal mask (and signal pending bitmap) couldn't be stored in user memory, allowing the userland threading system to swap out the mask without entering the kernel. I absolutely agree. I am thinking of a special page mapped in kernel and userspace memory, where things like signal mask and pending (per thread) are located, and maybe also a timecounter, pid, etc. So I think there is a very good argument for making the current release implementation do these calls in libc and not as system calls, and initially have libc just get the signal mask with a system call, then at some later date add the feature sthat allow the userland context routines to run fully without having to make any system calls at all. If Matt Emmerton finds the time to implement it, I am all for it. Having these functions as syscalls seems wrong in my eyes. cheers simon
Re: Request for swapcontext and getcontext to be ported to our libc
Matthew Dillon wrote: The answer is: yes, it is possible. There is no reason why the signal mask (and signal pending bitmap) couldn't be stored in user memory, allowing the userland threading system to swap out the mask without entering the kernel. I absolutely agree. I am thinking of a special page mapped in kernel and userspace memory, where things like signal mask and pending (per thread) are located, and maybe also a timecounter, pid, etc. So I think there is a very good argument for making the current release implementation do these calls in libc and not as system calls, and initially have libc just get the signal mask with a system call, then at some later date add the feature sthat allow the userland context routines to run fully without having to make any system calls at all. If Matt Emmerton finds the time to implement it, I am all for it. Having these functions as syscalls seems wrong in my eyes. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
Re: Request for swapcontext and getcontext to be ported to our libc
Ok, well, I'll bring up a counterpoint - one that argues for it to remain in userland. When I examine the FreeBSD code, the ONLY thing the kernel does that one needs to be in kernel mode for is setting the signal mask. That's it. Everything else can be done in userland. So the question becomes, is it possible to have a threaded system where you can set the signal mask during a context switch and NOT have to switch into the kernel? The answer is: yes, it is possible. There is no reason why the signal mask (and signal pending bitmap) couldn't be stored in user memory, allowing the userland threading system to swap out the mask without entering the kernel. It would require having a system call that allows the userland threading system to specify the user address where the signal mask resides, but it could be done and it would not be difficult. So I think there is a very good argument for making the current release implementation do these calls in libc and not as system calls, and initially have libc just get the signal mask with a system call, then at some later date add the feature sthat allow the userland context routines to run fully without having to make any system calls at all. -Matt
Re: Request for swapcontext and getcontext to be ported to our libc
:However, I recall it being mentioned that the proliferation of syscalls is :unneccessary, so a libc implementation would keep the kernel lean. The :reason we need curthread is to get access to the frame construct, which is :neccessary to save the context. : :Regards, :-- :Matt Emmerton Nah. The frame is just made up of entirely user-accessible registers. The only thing that is kernel-only is the signal mask (and one can make a system call to get it). The FP state can be controlled in userland too. The really interesting thing about it is that if you do it in userland you don't have to save or restore the call-used registers. I think the FreeBSD folks did these as system calls because they believe the context switching routines may have to do other kernel-only things in the future. That isn't a bad argument. On the otherhand, if one is talking about operating in virtualized environments (any sort of virtualization), having to do a system call at all is very, very expensive. -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: RFR: Port of FreeBSD *context routines to DFly
:This sounds fine by me. I will let you do this -- it seems to me that there :are other functions in machdep.c that really belong in the cpu/ hierarchy as :well, although I don't have a very keen eye for the cpu/machine distinction :(at least on i386). : :Regards, :-- :Matt Emmerton Yes, you are absolutely correct... its because there WAS no cpu hierarchy a few weeks ago... it was a machine-only hiearchy. I created the cpu hiearchy and I've been slowly moving the cpu-specific code from pc32 into it on an as-needed basis (i.e. code that both VKERNEL and PC32 need). I'm going to hold off on any commits for a day or two so we can discuss the system-call vs userland issues a bit more. I am not leaning to either side, really. In my view it is ok to have a few system calls that later become obsolete... that's what the COMPAT options in the kernel build are for. -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: Request for swapcontext and getcontext to be ported to our libc
Matt Emmerton wrote: Simon wrote: Matt Emmerton wrote: I've toyed with it a bit, but there are some issues I'm not sure how to solve (such as accessing curthread -- a kernel construct -- from userland). I would welcome discussion with the person who suggested it (corecode?). In which way do you have to access curthread? That's a kernel-only entity, I don't think you have to access that in userland. Besides, if we take in the system call version, there is no need for a pure libc based version anymore. Point taken, and that's definitely the path we're going down at the moment. However, I recall it being mentioned that the proliferation of syscalls is unneccessary, so a libc implementation would keep the kernel lean. Once we have introduced this syscall, we can't remove it anymore for binary compatibility. The reason we need curthread is to get access to the frame construct, which is neccessary to save the context. when you are in userland, you have to build the frame yourself. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
Re: Request for swapcontext and getcontext to be ported to our libc
Simon wrote: > Matt Emmerton wrote: > > I've toyed with it a bit, but there are some issues I'm not sure how to > > solve (such as accessing curthread -- a kernel construct -- from userland). > > I would welcome discussion with the person who suggested it (corecode?). > > In which way do you have to access curthread? That's a kernel-only > entity, I don't think you have to access that in userland. Besides, if we > take in the system call version, there is no need for a pure libc based > version anymore. Point taken, and that's definitely the path we're going down at the moment. However, I recall it being mentioned that the proliferation of syscalls is unneccessary, so a libc implementation would keep the kernel lean. The reason we need curthread is to get access to the frame construct, which is neccessary to save the context. Regards, -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc
Petr, I'm starting on that now :) -- Matt Emmerton > I see. > What about getting someone to get powerdns-recusor compiling and running? > > Once that is done we shall arrange for your payment. > > Petr > > > Matt Emmerton wrote: > >> Hey, > >> Any progress on the fully libc *context functions? > >> > > > > I've toyed with it a bit, but there are some issues I'm not sure how to > > solve (such as accessing curthread -- a kernel construct -- from userland). > > I would welcome discussion with the person who suggested it (corecode?). > > > > Also, I felt it pertinent to focus on the quick-start FreeBSD port to get it > > into the 1.8-release. > > > > -- > > Matt Emmerton > > > > >
Re: RFR: Port of FreeBSD *context routines to DFly
> > :I have completed the port of [set|get|make|swap]context from FreeBSD to > :DFly. > : > :The latest patch set against HEAD (current as of Jan 12, 00:00 EST) is > :available here: http://www.gsicomp.on.ca/~matt/dfly > : > :I (and others) would really like to see this get into the release, so I > :would appreciate reviews and comments. Nothing too earth-shattering here - > :it's a straight port with some minor modifications due ot Matt's recent > :VKERNEL and trapframe changes. > : > :Regards, > :-- > :Matt Emmerton > > I will put it into the release. It looks good. The only thing I > would change is to put the new context code you added to > machine/pc32/i386/machdep.c into a new file in cpu/i386/misc instead, > so it can be used by both the VKERNEL and the PC32 builds. > > Unless you say otherwise, I will commit it later this evening. This sounds fine by me. I will let you do this -- it seems to me that there are other functions in machdep.c that really belong in the cpu/ hierarchy as well, although I don't have a very keen eye for the cpu/machine distinction (at least on i386). Regards, -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc
I see. What about getting someone to get powerdns-recusor compiling and running? Once that is done we shall arrange for your payment. Petr Matt Emmerton wrote: Hey, Any progress on the fully libc *context functions? I've toyed with it a bit, but there are some issues I'm not sure how to solve (such as accessing curthread -- a kernel construct -- from userland). I would welcome discussion with the person who suggested it (corecode?). Also, I felt it pertinent to focus on the quick-start FreeBSD port to get it into the 1.8-release. -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc
Matt Emmerton wrote: I've toyed with it a bit, but there are some issues I'm not sure how to solve (such as accessing curthread -- a kernel construct -- from userland). I would welcome discussion with the person who suggested it (corecode?). In which way do you have to access curthread? That's a kernel-only entity, I don't think you have to access that in userland. Besides, if we take in the system call version, there is no need for a pure libc based version anymore. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
Re: Request for swapcontext and getcontext to be ported to our libc
> Hey, > Any progress on the fully libc *context functions? I've toyed with it a bit, but there are some issues I'm not sure how to solve (such as accessing curthread -- a kernel construct -- from userland). I would welcome discussion with the person who suggested it (corecode?). Also, I felt it pertinent to focus on the quick-start FreeBSD port to get it into the 1.8-release. -- Matt Emmerton
Re: RFR: Port of FreeBSD *context routines to DFly
And also, has anything been done yet to get powerdns-recursor working? Petr Matt Emmerton wrote: I have completed the port of [set|get|make|swap]context from FreeBSD to DFly. The latest patch set against HEAD (current as of Jan 12, 00:00 EST) is available here: http://www.gsicomp.on.ca/~matt/dfly I (and others) would really like to see this get into the release, so I would appreciate reviews and comments. Nothing too earth-shattering here - it's a straight port with some minor modifications due ot Matt's recent VKERNEL and trapframe changes. Regards, -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc
Hey, Any progress on the fully libc *context functions? Petr
Re: RFR: Port of FreeBSD *context routines to DFly
:I have completed the port of [set|get|make|swap]context from FreeBSD to :DFly. : :The latest patch set against HEAD (current as of Jan 12, 00:00 EST) is :available here: http://www.gsicomp.on.ca/~matt/dfly : :I (and others) would really like to see this get into the release, so I :would appreciate reviews and comments. Nothing too earth-shattering here - :it's a straight port with some minor modifications due ot Matt's recent :VKERNEL and trapframe changes. : :Regards, :-- :Matt Emmerton I will put it into the release. It looks good. The only thing I would change is to put the new context code you added to machine/pc32/i386/machdep.c into a new file in cpu/i386/misc instead, so it can be used by both the VKERNEL and the PC32 builds. Unless you say otherwise, I will commit it later this evening. -Matt Matthew Dillon <[EMAIL PROTECTED]>
RFR: Port of FreeBSD *context routines to DFly
I have completed the port of [set|get|make|swap]context from FreeBSD to DFly. The latest patch set against HEAD (current as of Jan 12, 00:00 EST) is available here: http://www.gsicomp.on.ca/~matt/dfly I (and others) would really like to see this get into the release, so I would appreciate reviews and comments. Nothing too earth-shattering here - it's a straight port with some minor modifications due ot Matt's recent VKERNEL and trapframe changes. Regards, -- Matt Emmerton
Watching TV with DragonFly
Hi Guys, I want to watch TV with my Hauppauge WinTV/PCI (bt848) on my DragonFlyBSD-box. The card works: bktr0: mem 0xdff0-0xdff00fff irq 11 at device 9.0 on pci0 bktr0: Hauppauge Model 60124 C1V bktr0: Detected a MSP3400C-C6 at 0x80 bktr0: Hauppauge WinCast/TV, Philips FR1216 PAL FM tuner, msp3400c stereo. I can watch TV with xawtv using grabdisplay (with overlay-mode I only got a black screen). My favorite TV-application on BSD is mplayer, but I can't get it working on DragonFly: Playing tv://. TV file format detected. No such driver: bsdbt848 Any hints how to build mplayer with DragonFly-Support? Thanks in advance.
