閱讀文章 - 精華區 FB_current

發信人[email protected] (Julian Elischer),

看板FB_current

標題SF Bay area hackfest

發信站NCTU CSIE FreeBSD Server (Tue Mar 23 01:08:18 2004)

轉信站ptt!FreeBSD.csie.NCTU!not-for-mail

I've been thinking that we had so much fun at the dev summit here that it might be a good idea to have a hackfest here for local FreeBSD types.. Something like from Saturday noon to Sunday Noon. Good connectivity, good CVS mirrors, test machines etc, drinks and lotso parking.. LOTS of whiteboard :-)A If anyone thinks this would be good let me know and I can start working on it.. We always seem to get a lot done in the terminal room at USEnix etc. why not have a terminal room without the usenix? possible things for people to look at in groups.. we could even have people dial in for some purposes/discussions "why wait?" project expressd interest ---------------------------------------------- TLS/toolchain alfred, marcel, myself thread/sched interface myself, peter play with firewire kgdb me ??? ???? _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Doug White), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Tue Mar 23 02:11:50 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Mon, 22 Mar 2004, Julian Elischer wrote: > > I've been thinking that we had so much fun at the dev summit here that > it might be a good idea to have a hackfest here for local > FreeBSD types.. Something like from Saturday noon to Sunday Noon. > > Good connectivity, good CVS mirrors, test machines etc, drinks and > lotso parking.. LOTS of whiteboard :-)A Ah, the Vicor wall-o-whiteboard. I love that. :) > project expressd interest > ---------------------------------------------- > TLS/toolchain alfred, marcel, myself > thread/sched interface myself, peter > play with firewire kgdb me > ??? ???? I know, I know! "fix the devil spawn that is the ICH5" or "fix the devil spawn that is the ASUS ACPI code" :-) -- Doug White | FreeBSD: The Power to Serve [email protected] | www.FreeBSD.org _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Marcel Moolenaar), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Tue Mar 23 02:11:02 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Mon, Mar 22, 2004 at 05:18:53PM -0800, Julian Elischer wrote: > > project expressd interest > ---------------------------------------------- > TLS/toolchain alfred, marcel, myself A couple of things come together: o gdb upgrade o New kdb framework o TLS support + debugging o Thread debugging It would be really cool if we have the right people together so that we can deal with the interdependencies *and* have it developed/tested on all our platforms. It's really a lot of work and it helps to have a couple of people working on it who can discuss the issues face to face. > play with firewire kgdb me This fits in with the above. -- Marcel Moolenaar USPA: A-39004 [email protected] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Scott Long), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Tue Mar 23 02:33:20 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Mon, 22 Mar 2004, Julian Elischer wrote: > > I've been thinking that we had so much fun at the dev summit here that > it might be a good idea to have a hackfest here for local > FreeBSD types.. Something like from Saturday noon to Sunday Noon. > > Good connectivity, good CVS mirrors, test machines etc, drinks and > lotso parking.. LOTS of whiteboard :-)A > > If anyone thinks this would be good let me know and I can start working > on it.. > > We always seem to get a lot done in the terminal room at USEnix etc. > why not have a terminal room without the usenix? > > possible things for people to look at in groups.. > we could even have people dial in for some purposes/discussions > > "why wait?" > > > project expressd interest > ---------------------------------------------- > TLS/toolchain alfred, marcel, myself > thread/sched interface myself, peter > play with firewire kgdb me > ??? ???? > > I'd love to attend, but my ability to get to the BA is limited. Any chance there could be some sort of interactive, or at least streaming, audio? Scott _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Daniel Eischen), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Tue Mar 23 03:08:25 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Mon, 22 Mar 2004, Marcel Moolenaar wrote: > On Mon, Mar 22, 2004 at 05:18:53PM -0800, Julian Elischer wrote: > > > > project expressd interest > > ---------------------------------------------- > > TLS/toolchain alfred, marcel, myself > > A couple of things come together: > o gdb upgrade > o New kdb framework > o TLS support + debugging > o Thread debugging David Xu has thread debugging working with a slightly modified thread-db.c in our current GDB. Regardless, thread debugging is not currently working for our default threading library as it is currently installed, so breaking something that is already broken by importing a new toolchain isn't really a problem in my mind. -- Dan Eischen _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Julian Elischer), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Tue Mar 23 06:19:33 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Mon, 22 Mar 2004, Scott Long wrote: > On Mon, 22 Mar 2004, Julian Elischer wrote: > > > > I've been thinking that we had so much fun at the dev summit here that > > it might be a good idea to have a hackfest here for local > > FreeBSD types.. Something like from Saturday noon to Sunday Noon. > > > > Good connectivity, good CVS mirrors, test machines etc, drinks and > > lotso parking.. LOTS of whiteboard :-)A > > > > If anyone thinks this would be good let me know and I can start working > > on it.. > > > > We always seem to get a lot done in the terminal room at USEnix etc. > > why not have a terminal room without the usenix? > > > > possible things for people to look at in groups.. > > we could even have people dial in for some purposes/discussions > > > > "why wait?" > > > > > > project expressd interest > > ---------------------------------------------- > > TLS/toolchain alfred, marcel, myself > > thread/sched interface myself, peter > > play with firewire kgdb me > > ??? ???? > > > > > > I'd love to attend, but my ability to get to the BA is limited. Any > chance there could be some sort of interactive, or at least streaming, > audio? I was thinking that we could have several 'working goups and that a couple of them could have access to 'meeting room phones' and would be able to conference people in who wanted to work on some particular thing but were not in the BA.. of course that is a limited facility but we could have a couple of people from outside help those here, here and there :-) > > Scott > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] ("David O'Brien"), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Tue Mar 23 15:53:21 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Mon, Mar 22, 2004 at 06:33:03PM -0800, Marcel Moolenaar wrote: > On Mon, Mar 22, 2004 at 05:18:53PM -0800, Julian Elischer wrote: > > > > project expressd interest > > ---------------------------------------------- > > TLS/toolchain alfred, marcel, myself > > A couple of things come together: > o gdb upgrade > o New kdb framework > o TLS support + debugging > o Thread debugging I still haven't seen any plan or commitment for LTS and GDB. Other than pushing me to spend my time importing a new binutils (which is broken for sparc64). If I import a new binutils, you need a new GCC to take full advantage of it. After GCC 3.4 is imported, what *commitments* are people willing to make to carry it farther? What will that work entail? Note that ANYONE that hacks on our GDB should have FSF paperwork on file. We HAVE to get out of the mess of all of our local hacks. The reason ports/devel/gdb6 still isn't active is the mess of bringing our GDB 5.2 hacks forward to GDB 6.1. I've had a WIP for a while, but it is really painful because we haven't done any due diligence in getting our needs taken care of in stock FSF GDB. That hasn't been able to happen to date because the people that made many of our GDB commits wouldn't file FSF paperwork. :-( _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Julian Elischer), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Tue Mar 23 18:05:43 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Tue, 23 Mar 2004, David O'Brien wrote: > On Mon, Mar 22, 2004 at 06:33:03PM -0800, Marcel Moolenaar wrote: > > On Mon, Mar 22, 2004 at 05:18:53PM -0800, Julian Elischer wrote: > > > > > > project expressd interest > > > ---------------------------------------------- > > > TLS/toolchain alfred, marcel, myself > > > > A couple of things come together: > > o gdb upgrade > > o New kdb framework > > o TLS support + debugging > > o Thread debugging > > I still haven't seen any plan or commitment for LTS and GDB. Other than > pushing me to spend my time importing a new binutils (which is broken for > sparc64). If I import a new binutils, you need a new GCC to take full > advantage of it. After GCC 3.4 is imported, what *commitments* are > people willing to make to carry it farther? What will that work entail? > > Note that ANYONE that hacks on our GDB should have FSF paperwork on file. > We HAVE to get out of the mess of all of our local hacks. The reason > ports/devel/gdb6 still isn't active is the mess of bringing our GDB 5.2 > hacks forward to GDB 6.1. I've had a WIP for a while, but it is really > painful because we haven't done any due diligence in getting our needs > taken care of in stock FSF GDB. That hasn't been able to happen to date > because the people that made many of our GDB commits wouldn't file FSF > paperwork. :-( > With new binutils we should (*) be able, with minimal more work be able to generate statically linked binaries using TLS. (*) the loader needs to set some values into symbols and the thread scheduler needs code to allocate a segment of 'M' bytes every time it rceates a new thread and set a pointer to it.. (it already allocates some info but it needs to allocate 'M' bytes more) where 'M' is the statically detirmined TLS size. The next step would be to add code to the dynamic linker to be able to allocate TLS segments to modules as it loads them. The TLS spec pretty much outlines what needs to be done.. We NEED to do this.. it is not a "may be nice" item. TLS is becoming standard on many platforms and more and more software is ASSUMING it is present. (e.g. nvidia drivers). _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Scott Long), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed, 24 Mar 2004 05:08:45 +0800 (CST)) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Tue, 23 Mar 2004, Julian Elischer wrote: > > > On Tue, 23 Mar 2004, David O'Brien wrote: > > > On Mon, Mar 22, 2004 at 06:33:03PM -0800, Marcel Moolenaar wrote: > > > On Mon, Mar 22, 2004 at 05:18:53PM -0800, Julian Elischer wrote: > > > > > > > > project expressd interest > > > > ---------------------------------------------- > > > > TLS/toolchain alfred, marcel, myself > > > > > > A couple of things come together: > > > o gdb upgrade > > > o New kdb framework > > > o TLS support + debugging > > > o Thread debugging > > > > I still haven't seen any plan or commitment for LTS and GDB. Other than > > pushing me to spend my time importing a new binutils (which is broken for > > sparc64). If I import a new binutils, you need a new GCC to take full > > advantage of it. After GCC 3.4 is imported, what *commitments* are > > people willing to make to carry it farther? What will that work entail? > > > > Note that ANYONE that hacks on our GDB should have FSF paperwork on file. > > We HAVE to get out of the mess of all of our local hacks. The reason > > ports/devel/gdb6 still isn't active is the mess of bringing our GDB 5.2 > > hacks forward to GDB 6.1. I've had a WIP for a while, but it is really > > painful because we haven't done any due diligence in getting our needs > > taken care of in stock FSF GDB. That hasn't been able to happen to date > > because the people that made many of our GDB commits wouldn't file FSF > > paperwork. :-( > > > > With new binutils we should (*) be able, with minimal more work be able > to generate statically linked binaries using TLS. (*) the loader needs > to set some values into symbols and the thread scheduler needs code to > allocate a segment of 'M' bytes every time it rceates a new thread and > set a pointer to it.. (it already allocates some info but it needs to > allocate 'M' bytes more) where 'M' is the statically detirmined TLS > size. > > The next step would be to add code to the dynamic linker to be able to > allocate TLS segments to modules as it loads them. The TLS spec pretty > much outlines what needs to be done.. > > We NEED to do this.. it is not a "may be nice" item. > TLS is becoming standard on many platforms and more and more software > is ASSUMING it is present. (e.g. nvidia drivers). > So what david is asking for (and what I've asked for in the past) is a list of tasks that need to be done, and and who is going to be responsible for each one. This is a very reasonable request, and is one that I'm going to enforce. I don't want 5.3 to go out with hap-hazard and/or unfinished TLS support. SO let me start the list, and I'll let you and others add to it. If we can't get through this step, then there is absolutely no way that we can expect to get this done for 5.3. And for the record, I would really, really like to see this done for 5.3. Task Owner Import new GCC Alexander Kavaev Import new binutils ??? Modify loader (image activator?) to understand TLS ??? Modify KSE to understand TLS ??? Modify THR to understand TLS ??? Modify C_R to understand TLS ??? Modify dynamic linker for TLS ??? What else? Is there any platform specific work to be done, outside of the toolchain? Scott _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Daniel Eischen), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Tue Mar 23 21:29:29 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Tue, 23 Mar 2004, Scott Long wrote: > On Tue, 23 Mar 2004, Julian Elischer wrote: > > > > With new binutils we should (*) be able, with minimal more work be able > > to generate statically linked binaries using TLS. (*) the loader needs > > to set some values into symbols and the thread scheduler needs code to > > allocate a segment of 'M' bytes every time it rceates a new thread and > > set a pointer to it.. (it already allocates some info but it needs to > > allocate 'M' bytes more) where 'M' is the statically detirmined TLS > > size. > > > > The next step would be to add code to the dynamic linker to be able to > > allocate TLS segments to modules as it loads them. The TLS spec pretty > > much outlines what needs to be done.. > > > > We NEED to do this.. it is not a "may be nice" item. > > TLS is becoming standard on many platforms and more and more software > > is ASSUMING it is present. (e.g. nvidia drivers). > > > > So what david is asking for (and what I've asked for in the past) is a > list of tasks that need to be done, and and who is going to be responsible > for each one. This is a very reasonable request, and is one that I'm For the KSE bits, we've already said a few times that we're ready to go but are waiting for a toolchain upgrade that supports TLS. > going to enforce. I don't want 5.3 to go out with hap-hazard and/or > unfinished TLS support. SO let me start the list, and I'll let you and > others add to it. If we can't get through this step, then there is > absolutely no way that we can expect to get this done for 5.3. And for > the record, I would really, really like to see this done for 5.3. I don't quite understand why you need commitments for a toolchain upgrade. From what I understand, TLS support can't happen without it, and by deferring the toolchain update you prevent it from getting done. But I'll play along regardless... > Task Owner > > Import new GCC Alexander Kavaev > Import new binutils ??? > Modify loader (image activator?) > to understand TLS ??? > Modify KSE to understand TLS ??? Yes, I'm sure I and/or David can support this. > Modify THR to understand TLS ??? > Modify C_R to understand TLS ??? Death to C_R, death to C_R, ... > Modify dynamic linker for TLS ??? > > What else? Is there any platform specific work to be done, outside of the > toolchain? -- Dan Eischen _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Julian Elischer), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 00:15:26 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Tue, 23 Mar 2004, Daniel Eischen wrote: > On Tue, 23 Mar 2004, Scott Long wrote: > > > On Tue, 23 Mar 2004, Julian Elischer wrote: > > > > > > With new binutils we should (*) be able, with minimal more work be able > > > to generate statically linked binaries using TLS. (*) the loader needs > > > to set some values into symbols and the thread scheduler needs code to > > > allocate a segment of 'M' bytes every time it rceates a new thread and > > > set a pointer to it.. (it already allocates some info but it needs to > > > allocate 'M' bytes more) where 'M' is the statically detirmined TLS > > > size. > > > > > > The next step would be to add code to the dynamic linker to be able to > > > allocate TLS segments to modules as it loads them. The TLS spec pretty > > > much outlines what needs to be done.. > > > > > > We NEED to do this.. it is not a "may be nice" item. > > > TLS is becoming standard on many platforms and more and more software > > > is ASSUMING it is present. (e.g. nvidia drivers). > > > > > > > So what david is asking for (and what I've asked for in the past) is a > > list of tasks that need to be done, and and who is going to be responsible > > for each one. This is a very reasonable request, and is one that I'm > > For the KSE bits, we've already said a few times that we're > ready to go but are waiting for a toolchain upgrade that > supports TLS. > > > going to enforce. I don't want 5.3 to go out with hap-hazard and/or > > unfinished TLS support. SO let me start the list, and I'll let you and > > others add to it. If we can't get through this step, then there is > > absolutely no way that we can expect to get this done for 5.3. And for > > the record, I would really, really like to see this done for 5.3. > > I don't quite understand why you need commitments for a toolchain > upgrade. From what I understand, TLS support can't happen without > it, and by deferring the toolchain update you prevent it from > getting done. But I'll play along regardless... > > > Task Owner > > > > Import new GCC Alexander Kavaev > > Import new binutils ??? > > Modify loader (image activator?) > > to understand TLS ??? > > Modify KSE to understand TLS ??? > > Yes, I'm sure I and/or David can support this. > > > Modify THR to understand TLS ??? > > Modify C_R to understand TLS ??? > > Death to C_R, death to C_R, ... I don't think we will support it. > > > Modify dynamic linker for TLS ??? > > > > What else? Is there any platform specific work to be done, outside of the > > toolchain? TLS is "kernel invisible" (other than what we have already done to make %gs point where we need it.) ((or the equivalent in other architectures) so there is no kernel work.. that leaves: the compiler the linker the assembler the dynamic linker The thread scheduler/library Off the top of my head, I believe these are all the players. The linker and dynamic linker are expected to 'plonk' snippets of machine dependent code into whereever an access to TLS is being made, depending on whether the access is to the same statically linked module or another module, loaded at run time, or the 'main' module. The "wheres" for these 'runtime code-insertions' are marked by the toolchain. The thread scheduler/library is expected to create new TLS segments whenever a new thread is created, and the linker is expected to request the thread library to add a new TLS segment to each exisiting thread whenever a new module is linked in that specifies TLS. The scheduler keeps pointers correct so that at any moment the correct TLS data is referenced when needed. As mentionned above the dynamic linker and the thread library have to co-operate about this. The compiler and assembler are expected to generate appropriate tokens and table entries for the run-time items to do the above when they need to. This should all be in place for Linux. There are optimisations that can be made.. for example lazy segment creation.. It is permissable to only allocate a TLS segment for a particular module, for a particular thread when that thread first tries to access said module's TLS data. that requires 'booby-trapping' all the relocation points but slows down the thread that have the segment allocated.. but you can sometimes gain this back by reduced data spread and cache effects. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Julian Elischer), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 00:39:22 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Tue, 23 Mar 2004, Julian Elischer wrote: > > > On Tue, 23 Mar 2004, Daniel Eischen wrote: > > > On Tue, 23 Mar 2004, Scott Long wrote: > > > > > On Tue, 23 Mar 2004, Julian Elischer wrote: > > > > > > > > With new binutils we should (*) be able, with minimal more work be able > > > > to generate statically linked binaries using TLS. (*) the loader needs > > > > to set some values into symbols and the thread scheduler needs code to > > > > allocate a segment of 'M' bytes every time it rceates a new thread and > > > > set a pointer to it.. (it already allocates some info but it needs to > > > > allocate 'M' bytes more) where 'M' is the statically detirmined TLS > > > > size. > > > > > > > > The next step would be to add code to the dynamic linker to be able to > > > > allocate TLS segments to modules as it loads them. The TLS spec pretty > > > > much outlines what needs to be done.. > > > > > > > > We NEED to do this.. it is not a "may be nice" item. > > > > TLS is becoming standard on many platforms and more and more software > > > > is ASSUMING it is present. (e.g. nvidia drivers). > > > > > > > > > > So what david is asking for (and what I've asked for in the past) is a > > > list of tasks that need to be done, and and who is going to be responsible > > > for each one. This is a very reasonable request, and is one that I'm > > > > For the KSE bits, we've already said a few times that we're > > ready to go but are waiting for a toolchain upgrade that > > supports TLS. > > > > > going to enforce. I don't want 5.3 to go out with hap-hazard and/or > > > unfinished TLS support. SO let me start the list, and I'll let you and > > > others add to it. If we can't get through this step, then there is > > > absolutely no way that we can expect to get this done for 5.3. And for > > > the record, I would really, really like to see this done for 5.3. > > > > I don't quite understand why you need commitments for a toolchain > > upgrade. From what I understand, TLS support can't happen without > > it, and by deferring the toolchain update you prevent it from > > getting done. But I'll play along regardless... > > > > > Task Owner > > > > > > Import new GCC Alexander Kavaev > > > Import new binutils ??? > > > Modify loader (image activator?) > > > to understand TLS ??? > > > Modify KSE to understand TLS ??? > > > > Yes, I'm sure I and/or David can support this. > > > > > Modify THR to understand TLS ??? > > > Modify C_R to understand TLS ??? > > > > Death to C_R, death to C_R, ... > > I don't think we will support it. I might add that after doing the work for M:N and N:N the code for 1:N may just "fall out" in which case we might look at doing it.. > > > > > > Modify dynamic linker for TLS ??? > > > > > > What else? Is there any platform specific work to be done, outside of the > > > toolchain? > > TLS is "kernel invisible" (other than what we have already done to make > %gs point where we need it.) ((or the equivalent in other > architectures) > so there is no kernel work.. > > that leaves: > > the compiler > the linker > the assembler > the dynamic linker > The thread scheduler/library > > Off the top of my head, I believe these are all the players. > > The linker and dynamic linker are expected to 'plonk' snippets of > machine dependent code into whereever an access to TLS is being made, > depending on whether the access is to the same statically linked module > or another module, loaded at run time, or the 'main' module. > The "wheres" for these 'runtime code-insertions' are marked by the > toolchain. > > The thread scheduler/library is expected to create new TLS segments > whenever a new thread is created, and the linker is expected to request > the thread library to add a new TLS segment to each exisiting thread > whenever a new module is linked in that specifies TLS. The scheduler > keeps pointers correct so that at any moment the correct TLS data is > referenced when needed. As mentionned above the dynamic linker and the > thread library have to co-operate about this. > > The compiler and assembler are expected to generate appropriate tokens > and table entries for the run-time items to do the above when they need > to. This should all be in place for Linux. > > There are optimisations that can be made.. > for example lazy segment creation.. > > It is permissable to only allocate a TLS segment for a particular > module, for a particular thread when that thread first tries to access > said module's TLS data. > that requires 'booby-trapping' all the relocation points but slows down > the thread that have the segment allocated.. but you can sometimes gain > this back by reduced data spread and cache effects. > > > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[email protected]" > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Daniel Eischen), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 00:45:51 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Tue, 23 Mar 2004, Julian Elischer wrote: > > On Tue, 23 Mar 2004, Julian Elischer wrote: > > > On Tue, 23 Mar 2004, Daniel Eischen wrote: > > > > > On Tue, 23 Mar 2004, Scott Long wrote: > > > > > > > Task Owner > > > > > > > > Import new GCC Alexander Kavaev > > > > Import new binutils ??? > > > > Modify loader (image activator?) > > > > to understand TLS ??? > > > > Modify KSE to understand TLS ??? > > > > > > Yes, I'm sure I and/or David can support this. > > > > > > > Modify THR to understand TLS ??? I should also be able to make it work for libthr if noone else minds/wants to. > > > > Modify C_R to understand TLS ??? > > > > > > Death to C_R, death to C_R, ... > > > > I don't think we will support it. > > I might add that after doing the work for M:N and N:N > the code for 1:N may just "fall out" in which case we might look at > doing it.. Right, it _should_ be easy enough. -- Dan Eischen _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (jason), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 00:53:48 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail Julian Elischer wrote: >On Mon, 22 Mar 2004, Scott Long wrote: > > > >>On Mon, 22 Mar 2004, Julian Elischer wrote: >> >> >>>I've been thinking that we had so much fun at the dev summit here that >>>it might be a good idea to have a hackfest here for local >>>FreeBSD types.. Something like from Saturday noon to Sunday Noon. >>> >>>Good connectivity, good CVS mirrors, test machines etc, drinks and >>>lotso parking.. LOTS of whiteboard :-)A >>> >>>If anyone thinks this would be good let me know and I can start working >>>on it.. >>> >>>We always seem to get a lot done in the terminal room at USEnix etc. >>>why not have a terminal room without the usenix? >>> >>>possible things for people to look at in groups.. >>>we could even have people dial in for some purposes/discussions >>> >>>"why wait?" >>> >>> >>>project expressd interest >>>---------------------------------------------- >>>TLS/toolchain alfred, marcel, myself >>>thread/sched interface myself, peter >>>play with firewire kgdb me >>>??? ???? >>> >>> >>> >>> >>I'd love to attend, but my ability to get to the BA is limited. Any >>chance there could be some sort of interactive, or at least streaming, >>audio? >> >> > >I was thinking that we could have several 'working goups and that a >couple of them could have access to 'meeting room phones' and would be >able to conference people in who wanted to work on some particular >thing but were not in the BA.. of course that is a limited facility but >we could have a couple of people from outside help those here, here and >there :-) > > > Have you heard of team speak? I use it with my friends to conference call while on battle.net and it works great for us. It is also in the ports system. It sounds like just what you are looking for. Jason _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Julian Elischer), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 01:35:09 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Mon, 22 Mar 2004, Marcel Moolenaar wrote: > On Mon, Mar 22, 2004 at 05:18:53PM -0800, Julian Elischer wrote: > > > > project expressd interest > > ---------------------------------------------- > > TLS/toolchain alfred, marcel, myself > > A couple of things come together: > o gdb upgrade > o New kdb framework > o TLS support + debugging > o Thread debugging > Marcel where is your TLS page? I've lost it :-) > It would be really cool if we have the right people together so that > we can deal with the interdependencies *and* have it developed/tested > on all our platforms. It's really a lot of work and it helps to have > a couple of people working on it who can discuss the issues face to > face. > > > play with firewire kgdb me > > This fits in with the above. > > -- > Marcel Moolenaar USPA: A-39004 [email protected] > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Marcel Moolenaar), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 01:57:40 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Tue, Mar 23, 2004 at 05:37:04PM -0800, Julian Elischer wrote: > > Marcel where is your TLS page? I've lost it :-) http://people.FreeBSD.org/~marcel/tls.html -- Marcel Moolenaar USPA: A-39004 [email protected] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Scott Long), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 02:34:25 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Tue, 23 Mar 2004, Daniel Eischen wrote: > > For the KSE bits, we've already said a few times that we're > ready to go but are waiting for a toolchain upgrade that > supports TLS. > > > going to enforce. I don't want 5.3 to go out with hap-hazard and/or > > unfinished TLS support. SO let me start the list, and I'll let you and > > others add to it. If we can't get through this step, then there is > > absolutely no way that we can expect to get this done for 5.3. And for > > the record, I would really, really like to see this done for 5.3. > > I don't quite understand why you need commitments for a toolchain > upgrade. From what I understand, TLS support can't happen without > it, and by deferring the toolchain update you prevent it from > getting done. But I'll play along regardless... Operating without a plan or commitments leads us back to 2002 with KSE. If TLS needs a new binutils, then we need to figure out who is going to provide that. If no one is going to provide it, then the rest is futile, no? > > > Task Owner > > > > Import new GCC Alexander Kavaev > > Import new binutils ??? > > Modify loader (image activator?) > > to understand TLS ??? > > Modify KSE to understand TLS ??? > > Yes, I'm sure I and/or David can support this. > > > Modify THR to understand TLS ??? > > Modify C_R to understand TLS ??? > > Death to C_R, death to C_R, ... > What happens when the compiler, toolchain, etc, etc, are all updated to make TLS work, but the user libmaps C_R in? Does stuff blow up? I'm ok with C_R not explicitely supporting it so long as it doesn't create new failure cases. Maybe this task list can be appended to Marcel's page and then linked somewhere prominently. If not then I'll create a new project page for it. Scott _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Scott Long), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 03:47:08 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Tue, 23 Mar 2004, Julian Elischer wrote: > > > > > > What else? Is there any platform specific work to be done, outside of the > > > toolchain? > > TLS is "kernel invisible" (other than what we have already done to make > %gs point where we need it.) ((or the equivalent in other > architectures) > so there is no kernel work.. > > that leaves: > > the compiler > the linker > the assembler > the dynamic linker > The thread scheduler/library > > Off the top of my head, I believe these are all the players. > > The linker and dynamic linker are expected to 'plonk' snippets of > machine dependent code into whereever an access to TLS is being made, > depending on whether the access is to the same statically linked module > or another module, loaded at run time, or the 'main' module. > The "wheres" for these 'runtime code-insertions' are marked by the > toolchain. > > The thread scheduler/library is expected to create new TLS segments > whenever a new thread is created, and the linker is expected to request > the thread library to add a new TLS segment to each exisiting thread > whenever a new module is linked in that specifies TLS. The scheduler > keeps pointers correct so that at any moment the correct TLS data is > referenced when needed. As mentionned above the dynamic linker and the > thread library have to co-operate about this. > > The compiler and assembler are expected to generate appropriate tokens > and table entries for the run-time items to do the above when they need > to. This should all be in place for Linux. This sounds fine. Feel free to expand the task list with more detail like this. > > There are optimisations that can be made.. > for example lazy segment creation.. > > It is permissable to only allocate a TLS segment for a particular > module, for a particular thread when that thread first tries to access > said module's TLS data. > that requires 'booby-trapping' all the relocation points but slows down > the thread that have the segment allocated.. but you can sometimes gain > this back by reduced data spread and cache effects. > Let's get basic functionality woring on x86 and amd64 before we start diverging into optimization strategies. Scott _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Daniel Eischen), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 06:41:14 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Tue, 23 Mar 2004, Scott Long wrote: > On Tue, 23 Mar 2004, Daniel Eischen wrote: > > > > For the KSE bits, we've already said a few times that we're > > ready to go but are waiting for a toolchain upgrade that > > supports TLS. > > > > > going to enforce. I don't want 5.3 to go out with hap-hazard and/or > > > unfinished TLS support. SO let me start the list, and I'll let you and > > > others add to it. If we can't get through this step, then there is > > > absolutely no way that we can expect to get this done for 5.3. And for > > > the record, I would really, really like to see this done for 5.3. > > > > I don't quite understand why you need commitments for a toolchain > > upgrade. From what I understand, TLS support can't happen without > > it, and by deferring the toolchain update you prevent it from > > getting done. But I'll play along regardless... > > Operating without a plan or commitments leads us back to 2002 with KSE. > If TLS needs a new binutils, then we need to figure out who is going to > provide that. If no one is going to provide it, then the rest is futile, > no? Right, but the prerequisite for TLS is a new toolchain, not the other way around; you don't need TLS support in non-toolchain components to update the toolchain. Once the toolchain supports TLS, support for it can be added at any time, regardless of whether or not it is before or after 5.3. And yes, we (thread-guys) would like to support it for 5.3 and have said so for quite some time. We've already rearranged our per-{thread,KSE} storage to allow for it. > > > Task Owner > > > > > > Import new GCC Alexander Kavaev > > > Import new binutils ??? > > > Modify loader (image activator?) > > > to understand TLS ??? > > > Modify KSE to understand TLS ??? > > > > Yes, I'm sure I and/or David can support this. > > > > > Modify THR to understand TLS ??? > > > Modify C_R to understand TLS ??? > > > > Death to C_R, death to C_R, ... > > > > What happens when the compiler, toolchain, etc, etc, are all updated to > make TLS work, but the user libmaps C_R in? Does stuff blow up? I'm ok > with C_R not explicitely supporting it so long as it doesn't create new > failure cases. I guess stuff blows up, probably very similar to what already happens when someone tries to use nvidia drivers/openGL with libpthread or libthr. But as far as I know, nothing we have is currently built to use it (it probably can't be because our released toolchain first needs to support it). -- Dan Eischen _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Scott Long), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 07:17:26 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, Daniel Eischen wrote: > On Tue, 23 Mar 2004, Scott Long wrote: > > > On Tue, 23 Mar 2004, Daniel Eischen wrote: > > > > > > For the KSE bits, we've already said a few times that we're > > > ready to go but are waiting for a toolchain upgrade that > > > supports TLS. > > > > > > > going to enforce. I don't want 5.3 to go out with hap-hazard and/or > > > > unfinished TLS support. SO let me start the list, and I'll let you and > > > > others add to it. If we can't get through this step, then there is > > > > absolutely no way that we can expect to get this done for 5.3. And for > > > > the record, I would really, really like to see this done for 5.3. > > > > > > I don't quite understand why you need commitments for a toolchain > > > upgrade. From what I understand, TLS support can't happen without > > > it, and by deferring the toolchain update you prevent it from > > > getting done. But I'll play along regardless... > > > > Operating without a plan or commitments leads us back to 2002 with KSE. > > If TLS needs a new binutils, then we need to figure out who is going to > > provide that. If no one is going to provide it, then the rest is futile, > > no? > > Right, but the prerequisite for TLS is a new toolchain, not the > other way around; you don't need TLS support in non-toolchain > components to update the toolchain. Once the toolchain supports > TLS, support for it can be added at any time, regardless of whether > or not it is before or after 5.3. And yes, we (thread-guys) would > like to support it for 5.3 and have said so for quite some time. > We've already rearranged our per-{thread,KSE} storage to allow for > it. Maybe something got misunderstood, then. My intention was to create a list of tasks that need to be done in order to reach the final goal of having TLS work. New binutils is one of those tasks. I also wanted to stress that each task needs an owner, otherwise it won't get done. Don't make me pull out MSProject and do this in a Ven diagram =-) > > > > > What happens when the compiler, toolchain, etc, etc, are all updated to > > make TLS work, but the user libmaps C_R in? Does stuff blow up? I'm ok > > with C_R not explicitely supporting it so long as it doesn't create new > > failure cases. > > I guess stuff blows up, probably very similar to what already > happens when someone tries to use nvidia drivers/openGL with > libpthread or libthr. But as far as I know, nothing we have > is currently built to use it (it probably can't be because > our released toolchain first needs to support it). > This isn't terribly desirable since C_R is going to be the fallback thread package for 5.x. Is there any way for C_R to detect when it's in a position to blow up and/or give an intelligent message to the user? Scott _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Julian Elischer), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 07:46:28 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, Scott Long wrote: > On Wed, 24 Mar 2004, Daniel Eischen wrote: > > On Tue, 23 Mar 2004, Scott Long wrote: > > > > > On Tue, 23 Mar 2004, Daniel Eischen wrote: > > > > > > > > For the KSE bits, we've already said a few times that we're > > > > ready to go but are waiting for a toolchain upgrade that > > > > supports TLS. > > > > > > > > > going to enforce. I don't want 5.3 to go out with hap-hazard and/or > > > > > unfinished TLS support. SO let me start the list, and I'll let you and > > > > > others add to it. If we can't get through this step, then there is > > > > > absolutely no way that we can expect to get this done for 5.3. And for > > > > > the record, I would really, really like to see this done for 5.3. > > > > > > > > I don't quite understand why you need commitments for a toolchain > > > > upgrade. From what I understand, TLS support can't happen without > > > > it, and by deferring the toolchain update you prevent it from > > > > getting done. But I'll play along regardless... > > > > > > Operating without a plan or commitments leads us back to 2002 with KSE. > > > If TLS needs a new binutils, then we need to figure out who is going to > > > provide that. If no one is going to provide it, then the rest is futile, > > > no? > > > > Right, but the prerequisite for TLS is a new toolchain, not the > > other way around; you don't need TLS support in non-toolchain > > components to update the toolchain. Once the toolchain supports > > TLS, support for it can be added at any time, regardless of whether > > or not it is before or after 5.3. And yes, we (thread-guys) would > > like to support it for 5.3 and have said so for quite some time. > > We've already rearranged our per-{thread,KSE} storage to allow for > > it. > > Maybe something got misunderstood, then. My intention was to create > a list of tasks that need to be done in order to reach the final goal of > having TLS work. New binutils is one of those tasks. I also wanted to > stress that each task needs an owner, otherwise it won't get done. Don't > make me pull out MSProject and do this in a Ven diagram =-) > > > > > > > > > What happens when the compiler, toolchain, etc, etc, are all updated to > > > make TLS work, but the user libmaps C_R in? Does stuff blow up? I'm ok > > > with C_R not explicitely supporting it so long as it doesn't create new > > > failure cases. > > > > I guess stuff blows up, probably very similar to what already > > happens when someone tries to use nvidia drivers/openGL with > > libpthread or libthr. But as far as I know, nothing we have > > is currently built to use it (it probably can't be because > > our released toolchain first needs to support it). > > > > This isn't terribly desirable since C_R is going to be the fallback thread > package for 5.x. Is there any way for C_R to detect when it's in a > position to blow up and/or give an intelligent message to the user? The linker could almost DEFINITLY do this # myprog ld.so: "You are tring to link libc_r to a program using TLS. Use libpthread" # > > > Scott > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Doug Rabson), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 09:12:14 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wednesday 24 March 2004 00:36, Julian Elischer wrote: > The linker and dynamic linker are expected to 'plonk' snippets of > machine dependent code into whereever an access to TLS is being made, > depending on whether the access is to the same statically linked > module or another module, loaded at run time, or the 'main' module. > The "wheres" for these 'runtime code-insertions' are marked by the > toolchain. I'll take the dynamic linker if no-one else wants it. I'm not coming to the bay area to do it though :-). I've been seriously considering putting in symbol version support too. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Doug Rabson), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 09:12:14 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wednesday 24 March 2004 00:36, Julian Elischer wrote: > The linker and dynamic linker are expected to 'plonk' snippets of > machine dependent code into whereever an access to TLS is being made, > depending on whether the access is to the same statically linked > module or another module, loaded at run time, or the 'main' module. > The "wheres" for these 'runtime code-insertions' are marked by the > toolchain. I'll take the dynamic linker if no-one else wants it. I'm not coming to the bay area to do it though :-). I've been seriously considering putting in symbol version support too. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Daniel Eischen), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 12:47:24 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, Scott Long wrote: > On Wed, 24 Mar 2004, Daniel Eischen wrote: > > > What happens when the compiler, toolchain, etc, etc, are all updated to > > > make TLS work, but the user libmaps C_R in? Does stuff blow up? I'm ok > > > with C_R not explicitely supporting it so long as it doesn't create new > > > failure cases. > > > > I guess stuff blows up, probably very similar to what already > > happens when someone tries to use nvidia drivers/openGL with > > libpthread or libthr. But as far as I know, nothing we have > > is currently built to use it (it probably can't be because > > our released toolchain first needs to support it). > > > > This isn't terribly desirable since C_R is going to be the fallback thread > package for 5.x. Is there any way for C_R to detect when it's in a > position to blow up and/or give an intelligent message to the user? It's probably easier just to add TLS support to libc_r if it's highly desirable. -- Dan Eischen _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Daniel Eischen), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 12:47:24 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, Doug Rabson wrote: > On Wednesday 24 March 2004 00:36, Julian Elischer wrote: > > The linker and dynamic linker are expected to 'plonk' snippets of > > machine dependent code into whereever an access to TLS is being made, > > depending on whether the access is to the same statically linked > > module or another module, loaded at run time, or the 'main' module. > > The "wheres" for these 'runtime code-insertions' are marked by the > > toolchain. > > I'll take the dynamic linker if no-one else wants it. I'm not coming to > the bay area to do it though :-). I've been seriously considering > putting in symbol version support too. Yes, please! -- Dan Eischen _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Daniel Eischen), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 12:47:24 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, Doug Rabson wrote: > On Wednesday 24 March 2004 00:36, Julian Elischer wrote: > > The linker and dynamic linker are expected to 'plonk' snippets of > > machine dependent code into whereever an access to TLS is being made, > > depending on whether the access is to the same statically linked > > module or another module, loaded at run time, or the 'main' module. > > The "wheres" for these 'runtime code-insertions' are marked by the > > toolchain. > > I'll take the dynamic linker if no-one else wants it. I'm not coming to > the bay area to do it though :-). I've been seriously considering > putting in symbol version support too. Yes, please! -- Dan Eischen _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Scott Long), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 18:35:31 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail Daniel Eischen wrote: > On Wed, 24 Mar 2004, Scott Long wrote: > > >>On Wed, 24 Mar 2004, Daniel Eischen wrote: >> >>>>What happens when the compiler, toolchain, etc, etc, are all updated to >>>>make TLS work, but the user libmaps C_R in? Does stuff blow up? I'm ok >>>>with C_R not explicitely supporting it so long as it doesn't create new >>>>failure cases. >>> >>>I guess stuff blows up, probably very similar to what already >>>happens when someone tries to use nvidia drivers/openGL with >>>libpthread or libthr. But as far as I know, nothing we have >>>is currently built to use it (it probably can't be because >>>our released toolchain first needs to support it). >>> >> >>This isn't terribly desirable since C_R is going to be the fallback thread >>package for 5.x. Is there any way for C_R to detect when it's in a >>position to blow up and/or give an intelligent message to the user? > > > It's probably easier just to add TLS support to libc_r if it's > highly desirable. > Note that it's highly desirable, but not the highest priority. So our table is now: Task Owner Import new GCC Alexander Kabaev Import new binutils ??? Modify loader (image activator?) to understand TLS ??? Modify KSE to understand TLS Dan Eischen/David Xu Modify dynamic linker for TLS Doug Rabson Modify THR to understand TLS ??? Modify C_R to understand TLS ??? It looks like we are gaining critical mass on this. C_R and THR are less important, and I'd even be willing to take a look at them myself. David, can you help with the binutils? It sounds like there might be some issues with libbfd if binutils is upgraded but gdb is not. Can we discuss the options here? Thanks, Scott _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Daniel Eischen), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 19:02:39 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, Scott Long wrote: > Daniel Eischen wrote: > > > > It's probably easier just to add TLS support to libc_r if it's > > highly desirable. > > > > Note that it's highly desirable, but not the highest priority. > > So our table is now: > > > Task Owner > > Import new GCC Alexander Kabaev > Import new binutils ??? > Modify loader (image activator?) > to understand TLS ??? > Modify KSE to understand TLS Dan Eischen/David Xu > Modify dynamic linker for TLS Doug Rabson > Modify THR to understand TLS ??? I've said I'll sign up for libthr in lieu of anyone else wanting to or objecting... I'd make sure KSE got done first, though. -- Dan Eischen _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Scott Long), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 19:02:39 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail Daniel Eischen wrote: > On Wed, 24 Mar 2004, Scott Long wrote: > > >>Daniel Eischen wrote: >> >>>It's probably easier just to add TLS support to libc_r if it's >>>highly desirable. >>> >> >>Note that it's highly desirable, but not the highest priority. >> >>So our table is now: >> >> >> Task Owner >> >> Import new GCC Alexander Kabaev >> Import new binutils ??? >> Modify loader (image activator?) >> to understand TLS ??? >> Modify KSE to understand TLS Dan Eischen/David Xu >> Modify dynamic linker for TLS Doug Rabson >> Modify THR to understand TLS ??? > > > I've said I'll sign up for libthr in lieu of anyone else > wanting to or objecting... I'd make sure KSE got done first, > though. > Sounds great! Scott _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] ("David O'Brien"), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 19:35:30 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, Mar 24, 2004 at 11:18:21AM -0700, Scott Long wrote: > It sounds like there might be > some issues with libbfd if binutils is upgraded but gdb is not. QUIT THIS FUD! _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Julian Elischer), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 19:49:41 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, Scott Long wrote: > Daniel Eischen wrote: > > On Wed, 24 Mar 2004, Scott Long wrote: > > > > > >>On Wed, 24 Mar 2004, Daniel Eischen wrote: > >> > >>>>What happens when the compiler, toolchain, etc, etc, are all updated to > >>>>make TLS work, but the user libmaps C_R in? Does stuff blow up? I'm ok > >>>>with C_R not explicitely supporting it so long as it doesn't create new > >>>>failure cases. > >>> > >>>I guess stuff blows up, probably very similar to what already > >>>happens when someone tries to use nvidia drivers/openGL with > >>>libpthread or libthr. But as far as I know, nothing we have > >>>is currently built to use it (it probably can't be because > >>>our released toolchain first needs to support it). > >>> > >> > >>This isn't terribly desirable since C_R is going to be the fallback thread > >>package for 5.x. Is there any way for C_R to detect when it's in a > >>position to blow up and/or give an intelligent message to the user? > > > > > > It's probably easier just to add TLS support to libc_r if it's > > highly desirable. > > > > Note that it's highly desirable, but not the highest priority. > > So our table is now: > > > Task Owner > > Import new GCC Alexander Kabaev > Import new binutils ??? > Modify loader (image activator?) > to understand TLS ??? > Modify KSE to understand TLS Dan Eischen/David Xu > Modify dynamic linker for TLS Doug Rabson > Modify THR to understand TLS ??? > Modify C_R to understand TLS ??? dogsbody and 2nd set of eyes.. julian(will be working with everyone I think) > > It looks like we are gaining critical mass on this. C_R and THR are > less important, and I'd even be willing to take a look at them myself. > David, can you help with the binutils? It sounds like there might be > some issues with libbfd if binutils is upgraded but gdb is not. Can we > discuss the options here? > > Thanks, > > Scott > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] ("David O'Brien"), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 20:33:17 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, Mar 24, 2004 at 11:18:21AM -0700, Scott Long wrote: > Task Owner > Import new binutils ??? This will happen late April to mid-May. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Julian Elischer), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 20:33:17 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail David if you have information that needs to be made public as to the state of the various tools WRT LTS support. this might be a good time for you to sumarise for the rest of us, the current state of play. That will help us cut down on the FUD and let us work out where we stand. On Wed, 24 Mar 2004, David O'Brien wrote: > On Wed, Mar 24, 2004 at 11:18:21AM -0700, Scott Long wrote: > > It sounds like there might be > > some issues with libbfd if binutils is upgraded but gdb is not. > > QUIT THIS FUD! > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Julian Elischer), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 20:33:17 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, David O'Brien wrote: > On Tue, Mar 23, 2004 at 04:49:51PM -0500, Daniel Eischen wrote: > > I don't quite understand why you need commitments for a toolchain > > upgrade. From what I understand, TLS support can't happen without > > it, and by deferring the toolchain update you prevent it from > > getting done. But I'll play along regardless... > > SMPng and KSE are both projects that haven't been completed because the > project only had commitments for the 1st part of the work. I refused to > pushed to import new toolchain bits for the to sit dormant not being > used. I'd rather use my time working on another part of FreeBSD if the > net of my time & effort is a NOP. Ok David, so KSE is now completed to the point that the toolchain is the bottleneck.. What's your beef? _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Julian Elischer), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 20:33:17 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, David O'Brien wrote: > On Wed, Mar 24, 2004 at 11:18:21AM -0700, Scott Long wrote: > > Task Owner > > Import new binutils ??? > > This will happen late April to mid-May. > thanks _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] ("David O'Brien"), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 20:33:17 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Tue, Mar 23, 2004 at 04:36:35PM -0800, Julian Elischer wrote: > TLS is "kernel invisible" (other than what we have already done to make > %gs point where we need it.) ((or the equivalent in other > architectures) > so there is no kernel work.. Uh, who is going to investigate the situation on the other platforms and make any needed changes? Lack of that is also a deal breaker. I won't participate in TLS if it is going to be yet another feature that makes our platforms not on equal footing. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Julian Elischer), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 20:47:44 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail who cares? On Wed, 24 Mar 2004, David O'Brien wrote: > On Tue, Mar 23, 2004 at 09:01:11PM -0700, Scott Long wrote: > > Let's get basic functionality woring on x86 and amd64 before we start > > diverging into optimization strategies. > > Uh, what about basic functionalty on Sparc64 and Alpha? > > -- > -- David ([email protected]) > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] ("David O'Brien"), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 20:56:50 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Tue, Mar 23, 2004 at 04:49:51PM -0500, Daniel Eischen wrote: > I don't quite understand why you need commitments for a toolchain > upgrade. From what I understand, TLS support can't happen without > it, and by deferring the toolchain update you prevent it from > getting done. But I'll play along regardless... SMPng and KSE are both projects that haven't been completed because the project only had commitments for the 1st part of the work. I refused to pushed to import new toolchain bits for the to sit dormant not being used. I'd rather use my time working on another part of FreeBSD if the net of my time & effort is a NOP. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] ("David O'Brien"), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 20:56:50 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Tue, Mar 23, 2004 at 09:01:11PM -0700, Scott Long wrote: > Let's get basic functionality woring on x86 and amd64 before we start > diverging into optimization strategies. Uh, what about basic functionalty on Sparc64 and Alpha? -- -- David ([email protected]) _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Scott Long), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 20:56:50 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail Julian Elischer wrote: > who cares? That's the wrong answer. There is a formal statement from the project that sparc64 is a tier-1 platform and also the reference platform for 64 bit support. The definition of tier-1 is that new functionality is added to all tier-1 platforms. This is no exception. I'm not going to re-open the tier discussion right now, though we indeed need to review it in the next month or two. For rgiht now, plan on supporting all tier-1 platforms. You don't need to necessarily write all the code yourself for these, but you have to be prepared to take them into consideration and take responsibility for getting the code written by someone. Scott > > On Wed, 24 Mar 2004, David O'Brien wrote: > > >>On Tue, Mar 23, 2004 at 09:01:11PM -0700, Scott Long wrote: >> >>>Let's get basic functionality woring on x86 and amd64 before we start >>>diverging into optimization strategies. >> >>Uh, what about basic functionalty on Sparc64 and Alpha? >> >>-- >>-- David ([email protected]) >> > > > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Julian Elischer), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 20:56:50 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, Scott Long wrote: > Julian Elischer wrote: > > who cares? > > That's the wrong answer. yes I know. It's just that we decided at the dev summit that we were dropping alpha as a tier one platform and everyone seems to have forgotten that. Sparc support is planned but we've had very little input from Sparc developers (are there any?) > There is a formal statement from the project > that sparc64 is a tier-1 platform and also the reference platform for 64 > bit support. The definition of tier-1 is that new functionality is > added to all tier-1 platforms. This is no exception. I'm not going to > re-open the tier discussion right now, though we indeed need to review > it in the next month or two. For rgiht now, plan on supporting all > tier-1 platforms. You don't need to necessarily write all the code > yourself for these, but you have to be prepared to take them into > consideration and take responsibility for getting the code written > by someone. > > Scott > > > > > On Wed, 24 Mar 2004, David O'Brien wrote: > > > > > >>On Tue, Mar 23, 2004 at 09:01:11PM -0700, Scott Long wrote: > >> > >>>Let's get basic functionality woring on x86 and amd64 before we start > >>>diverging into optimization strategies. > >> > >>Uh, what about basic functionalty on Sparc64 and Alpha? > >> > >>-- > >>-- David ([email protected]) > >> > > > > > > > > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Julian Elischer), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 20:56:50 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, David O'Brien wrote: > On Tue, Mar 23, 2004 at 04:36:35PM -0800, Julian Elischer wrote: > > TLS is "kernel invisible" (other than what we have already done to make > > %gs point where we need it.) ((or the equivalent in other > > architectures) > > so there is no kernel work.. > > Uh, who is going to investigate the situation on the other platforms and > make any needed changes? Lack of that is also a deal breaker. I won't > participate in TLS if it is going to be yet another feature that makes > our platforms not on equal footing. The other platform's KSE frameworks have been developed with TLS support already included. We already do all the kernel work that we need to (or at worst have done it in a way that the TLS support 'slots in'). I was just using X86 as an example. > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[email protected]" > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Julian Elischer), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 20:56:50 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, David O'Brien wrote: > On Tue, Mar 23, 2004 at 04:36:35PM -0800, Julian Elischer wrote: > > TLS is "kernel invisible" (other than what we have already done to make > > %gs point where we need it.) ((or the equivalent in other > > architectures) > > so there is no kernel work.. > > Uh, who is going to investigate the situation on the other platforms and > make any needed changes? Lack of that is also a deal breaker. I won't > participate in TLS if it is going to be yet another feature that makes > our platforms not on equal footing. > _______________________________________________ The only feature that wil put them on an unequal footing is if the toolchain support for one of them is incomplete, or we can not alter the run-time linker for one of them.. We designed the ABI for each to take TLS into account. > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[email protected]" > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Daniel Eischen), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 20:56:50 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, David O'Brien wrote: > On Tue, Mar 23, 2004 at 04:49:51PM -0500, Daniel Eischen wrote: > > I don't quite understand why you need commitments for a toolchain > > upgrade. From what I understand, TLS support can't happen without > > it, and by deferring the toolchain update you prevent it from > > getting done. But I'll play along regardless... > > SMPng and KSE are both projects that haven't been completed because the > project only had commitments for the 1st part of the work. I refused to > pushed to import new toolchain bits for the to sit dormant not being > used. I'd rather use my time working on another part of FreeBSD if the > net of my time & effort is a NOP. OK, that's certainly valid. -- Dan Eischen _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Brad Knowles), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 20:56:50 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail At 12:22 PM -0800 2004/03/24, Julian Elischer wrote: > who cares? > > On Wed, 24 Mar 2004, David O'Brien wrote: > >> On Tue, Mar 23, 2004 at 09:01:11PM -0700, Scott Long wrote: >> > Let's get basic functionality woring on x86 and amd64 before we start >> > diverging into optimization strategies. >> >> Uh, what about basic functionalty on Sparc64 and Alpha? Well, it depends. Would things be broken for SPARC64, or would it just not have TLS (which could presumably be added later)? If things would be broken for SPARC64, then I would be very disappointed to be unable to get my Ultra 10 clones up and working in the near future. -- Brad Knowles, <[email protected]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Julian Elischer), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 13:07:39 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, Brad Knowles wrote: > At 12:22 PM -0800 2004/03/24, Julian Elischer wrote: > > > who cares? > > > > On Wed, 24 Mar 2004, David O'Brien wrote: > > > >> On Tue, Mar 23, 2004 at 09:01:11PM -0700, Scott Long wrote: > >> > Let's get basic functionality woring on x86 and amd64 before we start > >> > diverging into optimization strategies. > >> > >> Uh, what about basic functionalty on Sparc64 and Alpha? > > Well, it depends. Would things be broken for SPARC64, or would > it just not have TLS (which could presumably be added later)? it would just mean that you could not do TLS.. umm I actually forget the state of Sparc KSE support now. we were waiting for help on something but I never heard if we got it.. I guess Dan would know. > > If things would be broken for SPARC64, then I would be very > disappointed to be unable to get my Ultra 10 clones up and working in > the near future. > > -- > Brad Knowles, <[email protected]> > > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > -Benjamin Franklin, Historical Review of Pennsylvania. > > GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ > !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) > tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Daniel Eischen), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 13:07:39 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, Julian Elischer wrote: > > On Wed, 24 Mar 2004, Scott Long wrote: > > > Julian Elischer wrote: > > > who cares? > > > > That's the wrong answer. > > yes I know. > > It's just that we decided at the dev summit that we were dropping alpha > as a tier one platform and everyone seems to have forgotten that. > Sparc support is planned but we've had very little input from Sparc > developers (are there any?) As far as KSE goes, we've tried getting someone to help us on sparc64 and alpha, but so far no-one has stepped forward. And TLS support for sparc64 and alpha can be added to libpthread regardless of whether the library is fully functional on those archs. > > There is a formal statement from the project > > that sparc64 is a tier-1 platform and also the reference platform for 64 > > bit support. The definition of tier-1 is that new functionality is > > added to all tier-1 platforms. This is no exception. I'm not going to > > re-open the tier discussion right now, though we indeed need to review > > it in the next month or two. For rgiht now, plan on supporting all > > tier-1 platforms. You don't need to necessarily write all the code > > yourself for these, but you have to be prepared to take them into > > consideration and take responsibility for getting the code written > > by someone. And you know that we have tried to do this. -- Dan Eischen _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Ken Smith), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 21:30:47 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, Mar 24, 2004 at 04:20:22PM -0500, Daniel Eischen wrote: > As far as KSE goes, we've tried getting someone to help us > on sparc64 and alpha, but so far no-one has stepped forward. I'm still on the low end of the learning curve but progressing slowly. If someone else is interested by all means feel free. If nobody else gets it done first I'll get it done eventually. -- Ken Smith - From there to here, from here to | [email protected] there, funny things are everywhere. | - Theodore Geisel | _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] ("David O'Brien"), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Wed Mar 24 23:27:15 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail [ Please don't top-post, it totally looses context; else I'll have to drop out of this discussion and doing the needed binutils import. ] On Wed, Mar 24, 2004 at 12:22:14PM -0800, Julian Elischer wrote: > On Wed, 24 Mar 2004, David O'Brien wrote: > > On Tue, Mar 23, 2004 at 09:01:11PM -0700, Scott Long wrote: > > > Let's get basic functionality woring on x86 and amd64 before we start > > > diverging into optimization strategies. > > > > Uh, what about basic functionalty on Sparc64 and Alpha? > > who cares? Need I remind you?? Tier 1: Fully Supported Architectures Tier 1 platforms are fully supported by the security officer, release engineering, and toolchain maintenance staff. New features added to the operating system must be fully functional across all Tier 1 architectures for every release (features which are inherently architecture-specific, such as support for hardware device drivers, may be exempt from this requirement). In general, all Tier 1 platforms must have build and tinderbox support either in the FreeBSD.org cluster, or easily available for all developers. Tier 1 architectures are expected to be Production Quality with respects to all aspects of the FreeBSD operating system, including installation and development environments. Current Tier 1 platforms are i386, Sparc64, AMD64, PC98, and Alpha. -- -- David ([email protected]) _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Garance A Drosihn), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Thu Mar 25 00:07:14 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail At 12:22 PM -0800 3/24/04, Julian Elischer wrote: >On Wed, 24 Mar 2004, David O'Brien wrote: >> > > Uh, what about basic functionalty on Sparc64 and Alpha? > >who cares? Given how many hours I just spent to provide a "somewhat painless" upgrade path on for a major change to sparc64, it would be correct to assume that I care about that platform. That doesn't mean I'm going to do all the sparc-related work for every project someone wants to implement on i386, but it does mean I want the platform to be taken seriously. It is going to be a major challenge to the FreeBSD project to have multiple "tier 1" platforms, and it isn't good to hear a cavalier "Who Cares?" so early in handling that challenge. -- Garance Alistair Drosehn = [email protected] Senior Systems Programmer or [email protected] Rensselaer Polytechnic Institute or [email protected] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Steve Kargl), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Thu Mar 25 01:44:01 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, Mar 24, 2004 at 07:56:15PM -0500, Garance A Drosihn wrote: > At 12:22 PM -0800 3/24/04, Julian Elischer wrote: > >On Wed, 24 Mar 2004, David O'Brien wrote: > >> > > > Uh, what about basic functionalty on Sparc64 and Alpha? > > > >who cares? > > I want the platform to be taken seriously. It is going to be a > major challenge to the FreeBSD project to have multiple "tier 1" > platforms, and it isn't good to hear a cavalier "Who Cares?" so > early in handling that challenge. > I'm not so sure that Julian was being cavalier. After watching Julian, Dan, and David repeatedly ask for a sparc64 (and alpha) person to help implement KSE, I suspect Julian was really asking "Who cares enough about sparc64 to help implement the missing pieces to get TLS moving forward?" >From where I sit on the side lines, this looks like a catch-22. David doesn't want to spend the time and effort to upgrade binutils without the commitment of implementing TLS on all tier-1 platforms. Julian and Dan don't want to make that commitment to all platforms until they had the opportunity to implement it on at least i386, which can't be done with a new toolchain. -- Steve _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Daniel Eischen), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Thu Mar 25 06:17:04 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, Steve Kargl wrote: > On Wed, Mar 24, 2004 at 07:56:15PM -0500, Garance A Drosihn wrote: > > At 12:22 PM -0800 3/24/04, Julian Elischer wrote: > > >On Wed, 24 Mar 2004, David O'Brien wrote: > > >> > > > > Uh, what about basic functionalty on Sparc64 and Alpha? > > > > > >who cares? > > > > I want the platform to be taken seriously. It is going to be a > > major challenge to the FreeBSD project to have multiple "tier 1" > > platforms, and it isn't good to hear a cavalier "Who Cares?" so > > early in handling that challenge. > > > > I'm not so sure that Julian was being cavalier. After watching > Julian, Dan, and David repeatedly ask for a sparc64 (and alpha) > person to help implement KSE, I suspect Julian was really asking > "Who cares enough about sparc64 to help implement the missing pieces > to get TLS moving forward?" > > From where I sit on the side lines, this looks like a catch-22. David > doesn't want to spend the time and effort to upgrade binutils without > the commitment of implementing TLS on all tier-1 platforms. Julian > and Dan don't want to make that commitment to all platforms until they > had the opportunity to implement it on at least i386, which can't be > done with a new toolchain. We've said this at other times, but TLS support is already partially designed in to libpthread (for all archs). We can (and will) implement it for them regardless of whether the library functions perfectly for those platforms. Both sparc64 and alpha seem to work OK when libpthread is built in 1:1 mode, so I suspect the real problem is resuming the thread contexts in userland and/or passing out the context in the expected format from the kernel. -- Dan Eischen _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] ("M. Warner Losh"), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Thu Mar 25 06:36:22 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail In message: <[email protected]> Julian Elischer <[email protected]> writes: : We always seem to get a lot done in the terminal room at USEnix etc. : why not have a terminal room without the usenix? Who needs those silly conferences and talks breaking up the good hacking that can be accomplished :-) Warner _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Julian Elischer), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Thu Mar 25 06:36:22 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, M. Warner Losh wrote: > In message: <[email protected]> > Julian Elischer <[email protected]> writes: > : We always seem to get a lot done in the terminal room at USEnix etc. > : why not have a terminal room without the usenix? > > Who needs those silly conferences and talks breaking up the good > hacking that can be accomplished :-) exactly! :-) > > Warner > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] ("M. Warner Losh"), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Thu Mar 25 06:36:22 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail : > Modify C_R to understand TLS ??? : : Death to C_R, death to C_R, ... I used to think that libc_r was cool. Now I'm in the death to it camp, but the conservative engineer side of me wonders if the embedded apps our company has will work on 5 (hard to try because we have custom drivers that need tweaking for 5). Warner _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Kris Kennaway), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Thu Mar 25 07:03:30 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail --K8nIJk4ghYZn606h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 25, 2004 at 01:22:22AM -0500, Daniel Eischen wrote: > We've said this at other times, but TLS support is already > partially designed in to libpthread (for all archs). We > can (and will) implement it for them regardless of whether > the library functions perfectly for those platforms. >=20 > Both sparc64 and alpha seem to work OK when libpthread is > built in 1:1 mode, so I suspect the real problem is resuming > the thread contexts in userland and/or passing out the > context in the expected format from the kernel. Can it be built that way by default on sparc, since libthr doesn't work very well? I'd like to test this for things like mozilla that cause libthr to crash at startup, except my sparc machine remains unbootable because of broken syscons. Kris --K8nIJk4ghYZn606h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAYo7HWry0BWjoQKURAgeWAJ9S9HBM7qnjgWD1W0GftgsIRyf6NACdEpOf Po8dELMqF6liMirTCcn/od4= =RS7N -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- > -------------------------------------------------------------------------- < 發信人: [email protected] (Daniel Eischen), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Fri Mar 26 05:24:36 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Wed, 24 Mar 2004, Kris Kennaway wrote: > On Thu, Mar 25, 2004 at 01:22:22AM -0500, Daniel Eischen wrote: > > > We've said this at other times, but TLS support is already > > partially designed in to libpthread (for all archs). We > > can (and will) implement it for them regardless of whether > > the library functions perfectly for those platforms. > > > > Both sparc64 and alpha seem to work OK when libpthread is > > built in 1:1 mode, so I suspect the real problem is resuming > > the thread contexts in userland and/or passing out the > > context in the expected format from the kernel. > > Can it be built that way by default on sparc, since libthr doesn't > work very well? I'd like to test this for things like mozilla that > cause libthr to crash at startup, except my sparc machine remains > unbootable because of broken syscons. Try adding -DSYSTEM_SCOPE_ONLY to CFLAGS when building libpthread, then try it and let me know how it works. libpthread is still built and installed as libkse on sparc64 (and alpha), so you'll also need to libmap libc_r to libkse. -- Dan Eischen _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Wes Peters), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Tue, 30 Mar 2004 13:48:18 +0800 (CST)) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Monday 22 March 2004 18:46, Scott Long wrote: > On Mon, 22 Mar 2004, Julian Elischer wrote: > > I've been thinking that we had so much fun at the dev summit here that > > it might be a good idea to have a hackfest here for local > > FreeBSD types.. Something like from Saturday noon to Sunday Noon. > > > > Good connectivity, good CVS mirrors, test machines etc, drinks and > > lotso parking.. LOTS of whiteboard :-)A > > > > If anyone thinks this would be good let me know and I can start working > > on it.. > > > > We always seem to get a lot done in the terminal room at USEnix etc. > > why not have a terminal room without the usenix? > > > > possible things for people to look at in groups.. > > we could even have people dial in for some purposes/discussions > > I'd love to attend, but my ability to get to the BA is limited. Any > chance there could be some sort of interactive, or at least streaming, > audio? I agree 100% with Julian, so much so that I've asked my employer if they'd be interested in hosting such a thing here in Sunny San Diego. It turns out we would. Not wanting to stomp on anyone's toes, I'd be happy to arrange such a think at a convenient time for people to gather. We might even be able to help with travel for a few select individuals, and to arrange group discounts for large contingents invading from the Bay Area. Since San Diego is such a fun place to visit, it would be a good idea to pander to hacker families as well. My wife has (been) volunteered to serve as tour guide and transportation coordinator for this endeavor, assisting spouses and offspring in identifying San Diego attractions, getting there, getting back, and getting covered with sunscreen in between. Anyone interested in such an outing, please contact me OFF-LIST. I'd like to know when might be a good time, how long you'd like to stay, etc. We can have the facilities at work over any weekend, but if we want to do weekdays, we'll have to arrange another space. St. Bernard will foot the bill for this up to a certain limit, and I happen to know a great space on Mission Bay, near SeaWorld. We will pre-arrange a reasonably fast network connection and wireless APs if we host offsite; we have those at work already. Weather-wise, San Diego has a very mild climate, with warm but not hot summers and cool but not cold winters. May and June tend to be gloomy and sometimes in October we burn down half the town, but other than that the weather varies from pretty good to gorgeous. -- Where am I, and what am I doing in this handbasket? Wes Peters [email protected] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Wes Peters), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Tue Mar 30 05:47:12 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail On Monday 22 March 2004 18:46, Scott Long wrote: > On Mon, 22 Mar 2004, Julian Elischer wrote: > > I've been thinking that we had so much fun at the dev summit here that > > it might be a good idea to have a hackfest here for local > > FreeBSD types.. Something like from Saturday noon to Sunday Noon. > > > > Good connectivity, good CVS mirrors, test machines etc, drinks and > > lotso parking.. LOTS of whiteboard :-)A > > > > If anyone thinks this would be good let me know and I can start working > > on it.. > > > > We always seem to get a lot done in the terminal room at USEnix etc. > > why not have a terminal room without the usenix? > > > > possible things for people to look at in groups.. > > we could even have people dial in for some purposes/discussions > > I'd love to attend, but my ability to get to the BA is limited. Any > chance there could be some sort of interactive, or at least streaming, > audio? I agree 100% with Julian, so much so that I've asked my employer if they'd be interested in hosting such a thing here in Sunny San Diego. It turns out we would. Not wanting to stomp on anyone's toes, I'd be happy to arrange such a think at a convenient time for people to gather. We might even be able to help with travel for a few select individuals, and to arrange group discounts for large contingents invading from the Bay Area. Since San Diego is such a fun place to visit, it would be a good idea to pander to hacker families as well. My wife has (been) volunteered to serve as tour guide and transportation coordinator for this endeavor, assisting spouses and offspring in identifying San Diego attractions, getting there, getting back, and getting covered with sunscreen in between. Anyone interested in such an outing, please contact me OFF-LIST. I'd like to know when might be a good time, how long you'd like to stay, etc. We can have the facilities at work over any weekend, but if we want to do weekdays, we'll have to arrange another space. St. Bernard will foot the bill for this up to a certain limit, and I happen to know a great space on Mission Bay, near SeaWorld. We will pre-arrange a reasonably fast network connection and wireless APs if we host offsite; we have those at work already. Weather-wise, San Diego has a very mild climate, with warm but not hot summers and cool but not cold winters. May and June tend to be gloomy and sometimes in October we burn down half the town, but other than that the weather varies from pretty good to gorgeous. -- Where am I, and what am I doing in this handbasket? Wes Peters [email protected] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]" > -------------------------------------------------------------------------- < 發信人: [email protected] (Nik Clayton), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Tue Mar 30 06:24:47 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail --UoPmpPX/dBe4BELn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 22, 2004 at 09:14:31PM -0800, Wes Peters wrote: > Not wanting to stomp on anyone's toes, I'd be happy to arrange such a thi= nk=20 > at a convenient time for people to gather. We might even be able to help= =20 > with travel for a few select individuals, and to arrange group discounts= =20 > for large contingents invading from the Bay Area. >=20 > Since San Diego is such a fun place to visit, it would be a good idea to= =20 > pander to hacker families as well. My wife has (been) volunteered to ser= ve=20 > as tour guide and transportation coordinator for this endeavor, assisting= =20 > spouses and offspring in identifying San Diego attractions, getting there= ,=20 > getting back, and getting covered with sunscreen in between. http://bsdcon.kiwki.org/ still exists -- feel free to use that to host pages of info about these sorts of thing. N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Project http://www.freebsd.org/docproj/ \\\'',) \/ \= ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/= _) --UoPmpPX/dBe4BELn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAaROuk6gHZCw343URAvR+AJ4s9Dkh254WoX2Dh2RN2PoPdH9sLwCfSgri QarhpD9s0En4P5+epagux+0= =ubqJ -----END PGP SIGNATURE----- --UoPmpPX/dBe4BELn-- > -------------------------------------------------------------------------- < 發信人: [email protected] (Nik Clayton), 看板: FB_current 標題: Re: SF Bay area hackfest 發信站: NCTU CSIE FreeBSD Server (Tue Mar 30 06:24:47 2004) 轉信站: ptt!FreeBSD.csie.NCTU!not-for-mail --UoPmpPX/dBe4BELn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 22, 2004 at 09:14:31PM -0800, Wes Peters wrote: > Not wanting to stomp on anyone's toes, I'd be happy to arrange such a thi= nk=20 > at a convenient time for people to gather. We might even be able to help= =20 > with travel for a few select individuals, and to arrange group discounts= =20 > for large contingents invading from the Bay Area. >=20 > Since San Diego is such a fun place to visit, it would be a good idea to= =20 > pander to hacker families as well. My wife has (been) volunteered to ser= ve=20 > as tour guide and transportation coordinator for this endeavor, assisting= =20 > spouses and offspring in identifying San Diego attractions, getting there= ,=20 > getting back, and getting covered with sunscreen in between. http://bsdcon.kiwki.org/ still exists -- feel free to use that to host pages of info about these sorts of thing. N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Project http://www.freebsd.org/docproj/ \\\'',) \/ \= ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/= _) --UoPmpPX/dBe4BELn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAaROuk6gHZCw343URAvR+AJ4s9Dkh254WoX2Dh2RN2PoPdH9sLwCfSgri QarhpD9s0En4P5+epagux+0= =ubqJ -----END PGP SIGNATURE----- --UoPmpPX/dBe4BELn--