Re: FILTER_SCHEDULE_THREAD is not a bit-value
Hello,
On Tue, Jan 31, 2012 at 12:44 AM, Ian Lepore
free...@damnhippie.dyndns.org wrote:
sys/bus.h documents the following semantics for FILTER_SCHEDULE_THREAD:
/**
* @brief Driver interrupt filter return values
*
* If a driver provides an interrupt filter routine it must return an
* integer consisting of oring together zero or more of the following
^^^
* flags:
*
* FILTER_STRAY - this device did not trigger the interrupt
* FILTER_HANDLED - the interrupt has been fully handled and can be
EOId
* FILTER_SCHEDULE_THREAD - the threaded interrupt handler should be
* scheduled to execute
*
* If the driver does not provide a filter, then the interrupt code will
* act is if the filter had returned FILTER_SCHEDULE_THREAD. Note that it
* is illegal to specify any other flag with FILTER_STRAY and that it is
* illegal to not specify either of FILTER_HANDLED or FILTER_SCHEDULE_THREAD
* if FILTER_STRAY is not specified.
*/
#define FILTER_STRAY 0x01
#define FILTER_HANDLED 0x02
#define FILTER_SCHEDULE_THREAD 0x04
But actually FILTER_SCHEDULE_THREAD is not used as a bit-value (see
kern/kern_intr.c):
if (!thread) {
if (ret == FILTER_SCHEDULE_THREAD)
thread = 1;
}
There is at least one in-tree driver that could be broken because of
this (asmc(8), but I found the problem with some other out-of-tree
driver).
This should be if (ret FILTER_SCHEDULE_THREAD) instead. Attached
patch fixes the problem.
What do you think?
Max
I think returning (FILTER_HANDLED | FILTER_SCHEDULE_THREAD) makes no
sense given the definition the interrupt has been fully handled and can
be EOId. If you EOI in the primary interrupt context and then schedule
a threaded handler to run as well you're likely to need complex locking
between the primary and threaded interrupt handlers and I was under the
impression that's just the sort of thing the filter/threaded scheme was
designed to avoid.
I see no sense here.
1) You would have to implement locking anyway to protect concurrent
access from ithread/filter and other driver methods (char device or
network device callbacks)
2) ithread and filter can already be executed simultaneously even when
only FILTER_SCHEDULE_THREAD is returned: when ithread is scheduled to
be executed the device can emit a new interrupt and it will be
preempted by filter
In other words, the part about ORing together values seems to be staking
out room for future growth, because the current set of flags and the
words about how to use them imply that only one of the current set of
values should be returned at once.
No, the text does not imply that only one of the values is supposed to
be returned (where did you see it). See also KASSERT checks in
intr_event_handle() -- they clearly show that the intention was to
allow FILTER_HANDLED and FILTER_SCHEDULE_THREAD to be returned
simultaneously.
Max
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FILTER_SCHEDULE_THREAD is not a bit-value
Hello!
sys/bus.h documents the following semantics for FILTER_SCHEDULE_THREAD:
/**
* @brief Driver interrupt filter return values
*
* If a driver provides an interrupt filter routine it must return an
* integer consisting of oring together zero or more of the following
^^^
* flags:
*
* FILTER_STRAY - this device did not trigger the interrupt
* FILTER_HANDLED - the interrupt has been fully handled and can be EOId
* FILTER_SCHEDULE_THREAD - the threaded interrupt handler should be
* scheduled to execute
*
* If the driver does not provide a filter, then the interrupt code will
* act is if the filter had returned FILTER_SCHEDULE_THREAD. Note that it
* is illegal to specify any other flag with FILTER_STRAY and that it is
* illegal to not specify either of FILTER_HANDLED or FILTER_SCHEDULE_THREAD
* if FILTER_STRAY is not specified.
*/
#define FILTER_STRAY 0x01
#define FILTER_HANDLED 0x02
#define FILTER_SCHEDULE_THREAD 0x04
But actually FILTER_SCHEDULE_THREAD is not used as a bit-value (see
kern/kern_intr.c):
if (!thread) {
if (ret == FILTER_SCHEDULE_THREAD)
thread = 1;
}
There is at least one in-tree driver that could be broken because of
this (asmc(8), but I found the problem with some other out-of-tree
driver).
This should be if (ret FILTER_SCHEDULE_THREAD) instead. Attached
patch fixes the problem.
What do you think?
Max
ithread.diff
Description: Binary data
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Remove debug echo
Garrett, On Thu, Dec 15, 2011 at 10:39 AM, Garrett Cooper yaneg...@gmail.com wrote: If someone would please, PLEASE commit this.. I will give you beer, or wine, or a copy of Skyrim, or a few months subscription to WoW, or something else of value to you that we could negotiate :)... I'm quite frankly tired of having to playing guessing games fishing through logs trying to determine build errors on FreeBSD if and when they do occur with pmake, and I'm sure that a number of developers and build/release engineers out there are in the same boat as I am. Can you explain why did you remove MESSAGE() invocations in your patch? Other than that the patch looks good to me. I thought that printing out MESSAGE and the more informative *printf was kind of redundant. Thanks! -Garrett PS A sidenote why I bypassed MESSAGE(..): if I used the macro, make would segfault as MESSAGE depends on targFmt and targPrefix being set to something sane (they both default to NULL -- one explicitly, the other implicitly because it's in the .BSS). These vars are only set in one section of code, but I took the easy route out to avoid accidentally breaking other code paths and because what I did in the previously attached patch was simple to implement and test. I did not mean that you should use MESSAGE() for your purposes, but removing existing invocations seems to be unnecessary. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Remove debug echo
Garrett,
On Thu, Dec 1, 2011 at 2:15 PM, Garrett Cooper yaneg...@gmail.com wrote:
I've attached a patch that makes make do what I would like it to do;
there are some other items that require cleanup to achieve the `argv0'
prefixing that's available in gmake, but this is good enough for a
meaningful traceback when things fail. Pastebin available here, just
in case the mailing list eats my patch: http://pastebin.com/dFqcDRfv
$ cat ~/Makefile
all:
cd $$HOME/foo; ${MAKE} $@
$ cat ~/foo/Makefile
all: foo bar barf yadda
foo bar yadda:
@true
baz:
@false
barf: baz
$ $PWD/make -j4 -f ~/Makefile all
cd $HOME/foo; /usr/src/usr.bin/make/make all
*** [baz] Error code 1
1 error
*** [all] Error code 2
1 error
$
If someone would please, PLEASE commit this.. I will give you beer, or
wine, or a copy of Skyrim, or a few months subscription to WoW, or
something else of value to you that we could negotiate :)... I'm quite
frankly tired of having to playing guessing games fishing through logs
trying to determine build errors on FreeBSD if and when they do occur
with pmake, and I'm sure that a number of developers and build/release
engineers out there are in the same boat as I am.
Can you explain why did you remove MESSAGE() invocations in your patch?
Other than that the patch looks good to me.
Max
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CVS removal from the base
Rik, On Sat, Dec 3, 2011 at 4:21 PM, Roman Kurakin r...@inse.ru wrote: The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. You are right in general, except one small factor. We are talking about bootstrap. CVS is used by many as the one of the ways to get the sources to the freshly installed system to recompile to the last available source. It will become inconvenient to do it through the process of installing some ports for that. Especially if corresponding ports would require some other ports as dependences. Do you really use CVS and not cvsup/csup? CVS != csup. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CVS removal from the base
Hello! On Sat, Dec 3, 2011 at 8:03 PM, sth...@nethelp.no wrote: I use CVS (or rather csup) to keep the base system up to date. I would be perfectly okay with using a different utility - however, I would strongly prefer that this utility was included in the base system. CVS != csup. I wonder how many people will express their sentiments about CVS when they really mean cvsup/csup. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing libreadline from base system
David, On Fri, Dec 2, 2011 at 3:17 PM, David O'Brien obr...@freebsd.org wrote: Agreed and known. If the application(s) using libreadline weren't already GPL I wouldn't have spoken up. When I added the libreadline compatibility to libedit, I changed all the non-GPL libreadline uses to libedit. Nope. You forgot heimdal stuff. If we have people willing to do the work now--as Max seems to be--then we might as well deal with the ports fallout from the removal of libreadline sooner rather than later. I guess this is the real agenda? To get ports to depend on an /usr/ports' version of libreadline? Agenda is available here: http://wiki.freebsd.org/GPLinBase If so, can it please wait 6 months until we've gotten thru the current nightmare that /usr/ports is on FreeBSD-CURRENT? Until this November that most ports would not build on -current, one still cannot 'pkg_add -r' anything, etc... Right now, I don't think we need another thing different between FreeBSD pre-10 and 10 that will be a /usr/ports headache. I would let portmgr and others decide on how long will the transition take. There is a PR about libreadline removal from base. It is being worked on. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing libreadline from base system
David, On Fri, Dec 2, 2011 at 3:43 PM, David O'Brien obr...@freebsd.org wrote: On Fri, Dec 02, 2011 at 12:57:20PM +0700, Max Khon wrote: On Fri, Dec 2, 2011 at 8:55 AM, David O'Brien obr...@freebsd.org wrote: If you go with (2) above, we'll still have *tons* of ports that want a libreadline, so we'll just end up growing a port of it and we'll wind up with a libreadline on the system anyway. Then you need to define what base system is. Eh? Its the same definition has been for the past 17 years -- that which is in /usr/src. As long as there is a GPL consumer of libreadline in /usr/src, there is no benefit to kicking libreadline out of /usr/src. I understand the anti-GPL sentiment -- I've done my share over the years to help achieve a GPL-free FreeBSD. But until there is a debugger that is anywhere near as capable (and mature) as GDB, we'll have a few GPL bits in /usr/src. I see that as OK -- its is small and contained. One of the suggested alternatives (that looks more viable to me now because of incompatibilities between libedit and libreadline) is to have libreadline as INTERNALLIB. So that it is not exposed outside of gdb build. So that if we ever decide to replace gdb with something else in the base all we have to do is to svn rm gdb and friends. In other words, I suggest to reduce the number of dependencies on base system libreadline to just base system gdb. E.g. we do not expose expat from our base system to the outside world because we do not want to have unnecessary dependencies between base and ports. Show me a non-GPL consumer of libreadline in /usr/src and I'll do everything I can to have it work with libedit. When I added the libreadline compatibility to libedit, I changed all the non-GPL libreadline uses I knew of to libedit. We have much more ports that depend on libintl or libglib2 than libreadline. Should we add these libs to the base system too? Please tell me what consumer of libintl or libglib2 we have in /usr/src. Your sentiment was about having libreadline port/package to be installed on almost every system. We already have such packages (libintl and libglib2) so there is nothing wrong with having libreadline as a port/package and it does not imply that we should have it installed with the base system. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WITHOUT_PROFILE=yes by default
David, On Fri, Dec 2, 2011 at 3:35 PM, David O'Brien obr...@freebsd.org wrote: On Fri, Dec 02, 2011 at 11:56:31AM +0700, Max Khon wrote: You still failed to name a single compelling reason to leave profiled libs even in -CURRENT. Sorry Joe, I don't think your reasoning is compelling. I'm sure you know how to stick NO_PROFILE=true in your /etc/src.conf. How far do you want to take this? By this reasoning we should set all the knobs to NO to speed up the build. I mean we're all competent code builders running FreeBSD-current and know how to enable knobs in /etc/src.conf. Is speeding up the build import important to you then the default base system being an comfortable featureful development environment? The most important thing is to have reasonable defaults. Having WITH_PROFILE by default does not seem to be a reasonable default to me. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
CVS removal from the base
Hello! I know that it is too early to speak about this, but I would like the dust in the mailing lists to settle down before real actions can be taken. As soon as ports/ (and doc/) are moved to SVN I do not see any compelling reasons for keeping CVS in the base system. Those who still use it for development can install ports/devel/opencvs (like all the src/ developers do for ports/devel/subversion/). In my opinion it is just another piece of bitrot that resides in the base system for no real reasons. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CVS removal from the base
Peter, On Fri, Dec 2, 2011 at 6:54 PM, Peter Jeremy peterjer...@acm.org wrote: On 2011-Dec-02 16:27:34 +0700, Max Khon f...@samodelkin.net wrote: I know that it is too early to speak about this, but I would like the dust in the mailing lists to settle down before real actions can be taken. I'd agree that it's still too early. As soon as ports/ (and doc/) are moved to SVN I do not see any compelling reasons for keeping CVS in the base system. There's more to it than just converting the repo from CVS to SVN - the official distribution and build systems have to be converted as well. I presumed that make release will use svn for doing ports/doc checkouts after repos are converted. The official build system for RELENG_8 remains CVS and (AFAIK) the official repo distribution system remains CVS-based (csup/cvsup) because there's no suitable SVN-based equivalent. I am not suggesting to change anything in RELENG_9 or even RELENG_8. And csup/cvsup != cvs. IMHO, if those issues can be resolved in the near future then it might be possible to deprecate CVS before 9.1 and remove it in 10 but I suspect removal in 11 is a more realistic timeframe. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WITHOUT_PROFILE=yes by default
Sevan, On Thu, Dec 1, 2011 at 6:56 AM, Sevan / Venture37 ventur...@gmail.comwrote: On 30/11/2011 16:03, Sevan / Venture37 wrote: system breaks if you try to add dtrace support to a system built with profile support. sorry, I meant *without* profile support. Are you sure you mean profile support and not CTF data? Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Remove debug echo
Garrett,
On Thu, Dec 1, 2011 at 2:15 PM, Garrett Cooper yaneg...@gmail.com wrote:
What I really want is this:
$ cat Makefile
all: foo bar baz yadda
foo bar yadda:
baz:
false
$ gmake
false
gmake: *** [baz] Error 1
$ make all
false
*** Error code 1
Stop in /tmp.
Otherwise diagnosing issues becomes a PITA with -j 1 (with pmake I
have to start using some serious grep'ing, and if I'm lucky I can find
the source of error). If I get a few spare cycles I might just
implement it and post a patch somewhere (the entering and leaving
directory feature of gmake is really nice too, but it's less
important.. unless you have the same target in multiple directories)..
I've attached a patch that makes make do what I would like it to do;
there are some other items that require cleanup to achieve the `argv0'
prefixing that's available in gmake, but this is good enough for a
meaningful traceback when things fail. Pastebin available here, just
in case the mailing list eats my patch: http://pastebin.com/dFqcDRfv
$ cat ~/Makefile
all:
cd $$HOME/foo; ${MAKE} $@
$ cat ~/foo/Makefile
all: foo bar barf yadda
foo bar yadda:
@true
baz:
@false
barf: baz
$ $PWD/make -j4 -f ~/Makefile all
cd $HOME/foo; /usr/src/usr.bin/make/make all
*** [baz] Error code 1
1 error
*** [all] Error code 2
1 error
$
If someone would please, PLEASE commit this.. I will give you beer, or
wine, or a copy of Skyrim, or a few months subscription to WoW, or
something else of value to you that we could negotiate :)... I'm quite
frankly tired of having to playing guessing games fishing through logs
trying to determine build errors on FreeBSD if and when they do occur
with pmake, and I'm sure that a number of developers and build/release
engineers out there are in the same boat as I am.
I hit the same problem regularly. The patch looks good to me as well.
Max
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing libreadline from base system
Brooks, On Fri, Dec 2, 2011 at 9:41 AM, Brooks Davis bro...@freebsd.org wrote: What is the value in doing either? libreadline isn't infecting any non-GPL code turning into GPLv2. Some of use have fancy .input files, and quite frankly the vi mode of libedit still doesn't work quite the same as libreadline. If you go with (2) above, we'll still have *tons* of ports that want a libreadline, so we'll just end up growing a port of it and we'll wind up with a libreadline on the system anyway. We are rapidly approaching the point where it will be practical to remove all GPL code from the base system (assuming we are willing to require external toolchains for some architectures) and a number of us are pushing to make this a reality for 10.0. If we have people willing to do the work now--as Max seems to be--then we might as well deal with the ports fallout from the removal of libreadline sooner rather than later. The existence of incompatibilities between libedit and libreadline probably does argue for option (2). Agree. I submitted the patch w/ INTERNALLIB for libreadline for 10.0 exp-run. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing libreadline from base system
David, On Fri, Dec 2, 2011 at 8:59 AM, David O'Brien obr...@freebsd.org wrote: This is a separate issue that I want to handle separately. I see no value in handling it separately. I either have a libreadline on my system or I don't. What I meant is that this problem is not related to the original question but it will be analyzed/resolved before the commit (if it will ever happen). I am not saying that my sole intention is to remove libreadline from base system. I just picked an item from here http://wiki.freebsd.org/GPLinBase and will come up with the analysis. If it turns out that libreadline removal is impractical it will not be removed. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WITHOUT_PROFILE=yes by default
David, On Fri, Dec 2, 2011 at 8:51 AM, David O'Brien obr...@freebsd.org wrote: On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote: I would like to disable building profiled libraries by default. Opinions? On Tue, Nov 29, 2011 at 07:46:17PM +, Max Khon wrote: Author: fjoe Date: Tue Nov 29 19:46:17 2011 New Revision: 228143 URL: http://svn.freebsd.org/changeset/base/228143 Log: Turn off profiled libs build by default. Can be enabled back using WITH_PROFILE=yes in /etc/src.conf Wow, a single day of discussion in freebsd-current@ was sufficient to invert a 17 year default. You still failed to name a single compelling reason to leave profiled libs even in -CURRENT. And it sounds like we should not fix 17-year old bugs or things that are no longer of any practical use because they were implemented 17 years ago. I'd like to see the profile libs remain built by default in -CURRENT. If you like, add it to the list of things to disable on -STABLE creation. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing libreadline from base system
David, On Fri, Dec 2, 2011 at 8:55 AM, David O'Brien obr...@freebsd.org wrote: If you go with (2) above, we'll still have *tons* of ports that want a libreadline, so we'll just end up growing a port of it and we'll wind up with a libreadline on the system anyway. Then you need to define what base system is. We have much more ports that depend on libintl or libglib2 than libreadline. Should we add these libs to the base system too? Also, almost all ports require gmake and autotools to be built. Should we add them to the base system too? Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WITHOUT_PROFILE=yes by default
Steve, On Fri, Dec 2, 2011 at 1:33 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Thu, Dec 01, 2011 at 05:51:33PM -0800, David O'Brien wrote: On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote: I would like to disable building profiled libraries by default. Opinions? On Tue, Nov 29, 2011 at 07:46:17PM +, Max Khon wrote: Author: fjoe Date: Tue Nov 29 19:46:17 2011 New Revision: 228143 URL: http://svn.freebsd.org/changeset/base/228143 Log: Turn off profiled libs build by default. Can be enabled back using WITH_PROFILE=yes in /etc/src.conf Wow, a single day of discussion in freebsd-current@ was sufficient to invert a 17 year default. I'd like to see the profile libs remain built by default in -CURRENT. +1 In particular, many (most, all?) people running -current will have profiled libaries installed. These libraries will become stale/out-of-sync with the static and shared libraries as (if) changes are made to libc. This is a completely different thing and is actually what ObsoleteFilesInc/OptionalObsoleteFiles.inc mechanism is for. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing libreadline from base system
Baptiste, On Tue, Nov 29, 2011 at 3:59 PM, Baptiste Daroussin b...@freebsd.orgwrote: It is possible to build and link our in-tree gdb friends with libedit after r228114. The remaining question is what to do with libreadline: 1) just build link gdb with libedit OR 2) re-import libreadline from gdb sources and build INTERNALLIB version of it that is never installed and is linked only to gdb I am inclined to go for 1) but libedit may have (and has) incompatibilities with libreadline. Back when I sent a libedit upgrade patch, before obrien update libedit on his own, I managed to build the whole tree with libedit, gdb, ntpc and others were fully functionnal with it, (at that time I totally removed libreadline) The whole src tree now builds without libreadline. The only problem I see is from the ports lots of them relies on base libreadline, so we need to first run an exp-run without libreadline, to determine the impact and fix the related ports, before we can fully dropped libreadline. This is a separate issue that I want to handle separately. The question is what to do with gdb friends. Link it with libedit or re-import bundled readline (that is shipped with gdb) and build/link it only to gdb. I am inclined to do the former. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
WITHOUT_PROFILE=yes by default
Hello! Are there any compelling reasons for having profiled libs to be built by default? They are of no use for 100% users and 99,999% developers and just slow down world and universe builds. Here are the results of running buildworld on 1 core on AMD Athlon(tm) 64 X2 Dual Core Processor 4400+: make buildworld 8265,06 real 6400,27 user 1059,2 sys make buildworld (WITHOUT_PROFILE=yes) 7840,05 real 5379,13 user 904,61 sys I would like to disable building profiled libraries by default. Opinions? Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WITHOUT_PROFILE=yes by default
Doug, On Tue, Nov 29, 2011 at 7:35 AM, Doug Barton do...@freebsd.org wrote: Are there any compelling reasons for having profiled libs to be built by default? Nope. It's been one of the first things I disable after I install a new system for at least a decade. Ideally we could do this for 9.0. Can we at least keep one (small) library compiled for profiling, so that compiling for profiling doesn't get broken by accident ? I think WITH_PROFILE is probably a good idea for the tinderbox? Who is in charge for tinderbox these days? Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
removing libreadline from base system
Hello! It is possible to build and link our in-tree gdb friends with libedit after r228114. The remaining question is what to do with libreadline: 1) just build link gdb with libedit OR 2) re-import libreadline from gdb sources and build INTERNALLIB version of it that is never installed and is linked only to gdb I am inclined to go for 1) but libedit may have (and has) incompatibilities with libreadline. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: More if_ath churn coming your way!
Adrian, On Thu, Jan 20, 2011 at 11:51 AM, Adrian Chadd adrian.ch...@gmail.comwrote: I'm in the process of merging in the non-intrusive changes to the if_ath code into -HEAD. I'd appreciate some testing just to ensure I haven't broken anything terribly obvious. Any chances for proper support for Atheros 802.11n cards? Should not we just port ath9k (Linux) or athn (OpenBSD) drivers? Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: VMWare build failure
Hello! On Thu, Nov 20, 2003 at 04:53:57PM -0600, Eric Anderson wrote: Guessing you're running -CURRENT you have the kernel source installed, so my suggestion is to run vmware3. Unless you have a specific reason to run 2? Maybe he doesn't run 3 because it also doesn't build: /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/freebsd/driver.c:303:35: i386/isa/intr_machdep.h: No such file or directory /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include/vm_asm.h: In function `Div643264': /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include/vm_asm.h:1033: warning: use of memory input without lvalue in asm operand 4 is deprecated *** Error code 1 Stop in /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only. *** Error code 1 Stop in /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only. *** Error code 1 Stop in /usr/ports/emulators/vmware3/work/vmware-distrib. *** Error code 1 Stop in /usr/ports/emulators/vmware3. *** Error code 1 Stop in /usr/ports/emulators/vmware3. So same thing with vmware3 - note that the file (intr_machdep.h) doesn't exist in that location - but it does in other locations. I tried copying one of the others over to that spot, and rebuilding, but still fails (with new errors as expected).. vmware3 port was fixed for non-SMP recently. please update your ports. /fjoe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fix for WINE on -CURRENT
Hello!
On Wed, Nov 05, 2003 at 05:50:35AM +0100, Simon Barner wrote:
can you make a patch for cdparanoia as well?
cdparanoia is also broken on recent -CURRENT and testing will be easy.
There is already a PR. I will rewise my patch to use __FreeBSD__ in the
patch file instead of using ${EXTRA_PATCHES}.
do you mean __FreeBSD_version?
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/57226
please revise the patch and submit follow-up.
This one here should be closed IMHO since there is a cleaner solution
that backing out the change.
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/58461
/fjoe
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PRs for dagrab and cdparanoia reworked (was: Re: Fix for WINE on -CURRENT)
Hello!
On Wed, Nov 05, 2003 at 02:10:02PM +0100, Simon Barner wrote:
please revise the patch and submit follow-up.
Done. Tested on both -STABLE and -CURRENT.
I am progress of doing the same for dagrab (expect a follow-up to PR
57227 soon).
There is no need for extra-patches.
#ifdef CDIOCREADAUDIO seems to be sufficient enough.
Is using CDRIOCSETBLOCKSIZE necessary as well?
If yes it shouold be done in enable_cdda callback I think.
Moreover, is there a reason we should use CDIOCREADAUDIO on RELENG_4?
Please test attached patch. works for me on RELENG_4 and should work
on -CURRENT as well.
/fjoe
Index: Makefile
===
RCS file: /home/pcvs/ports/audio/cdparanoia/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile14 Jul 2003 02:52:55 - 1.8
+++ Makefile5 Nov 2003 14:05:27 -
@@ -7,7 +7,7 @@
PORTNAME= cdparanoia
PORTVERSION= 3.9.8
-PORTREVISION= 5
+PORTREVISION= 6
CATEGORIES=audio sysutils
MASTER_SITES= http://www.xiph.org/paranoia/download/
DISTNAME= ${PORTNAME}-${PORTVERSION:C/^3\./III-alpha/}
Index: files/patch-interface-cooked_interface.c
===
RCS file: /home/pcvs/ports/audio/cdparanoia/files/patch-interface-cooked_interface.c,v
retrieving revision 1.2
diff -u -p -r1.2 patch-interface-cooked_interface.c
--- files/patch-interface-cooked_interface.c11 Jan 2003 09:15:00 - 1.2
+++ files/patch-interface-cooked_interface.c5 Nov 2003 14:38:09 -
@@ -1,11 +1,5 @@
-Index: interface/cooked_interface.c
-===
-RCS file: /home/cvs/cdparanoia/interface/cooked_interface.c,v
-retrieving revision 1.1.1.1
-retrieving revision 1.8
-diff -u -r1.1.1.1 -r1.8
interface/cooked_interface.c 2003/01/05 09:46:26 1.1.1.1
-+++ interface/cooked_interface.c 2003/01/11 08:58:45 1.8
+--- interface/cooked_interface.c.orig Thu Apr 20 05:41:04 2000
interface/cooked_interface.c Wed Nov 5 20:37:44 2003
@@ -1,6 +1,8 @@
/**
* CopyPolicy: GNU Public License 2 applies
@@ -23,7 +17,7 @@ diff -u -r1.1.1.1 -r1.8
static int cooked_readtoc (cdrom_drive *d){
int i;
int tracks;
-@@ -129,6 +132,128 @@
+@@ -129,6 +132,120 @@
return(sectors);
}
@@ -96,18 +90,10 @@ diff -u -r1.1.1.1 -r1.8
+cooked_read(cdrom_drive *d, void *p, long begin, long sectors)
+{
+ int retry_count = 0;
-+ struct ioc_read_audio arg;
-+
-+ if (sectors d-nsectors)
-+ sectors = d-nsectors;
-+
-+ arg.address_format = CD_LBA_FORMAT;
-+ arg.address.lba = begin;
-+ arg.buffer = p;
++ int bsize = CD_FRAMESIZE_RAW;
+
+ for (;;) {
-+ arg.nframes = sectors;
-+ if (ioctl(d-ioctl_fd, CDIOCREADAUDIO, arg) == -1) {
++ if (pread(d-ioctl_fd, p, sectors*bsize, begin*bsize) !=
sectors*bsize) {
+ if (!d-error_retry)
+ return -7;
+
@@ -152,7 +138,7 @@ diff -u -r1.1.1.1 -r1.8
/* hook */
static int Dummy (cdrom_drive *d,int Switch){
return(0);
-@@ -193,6 +318,7 @@
+@@ -193,6 +310,7 @@
int cooked_init_drive (cdrom_drive *d){
int ret;
@@ -160,7 +146,7 @@ diff -u -r1.1.1.1 -r1.8
switch(d-drive_type){
case MATSUSHITA_CDROM_MAJOR:/* sbpcd 1 */
case MATSUSHITA_CDROM2_MAJOR: /* sbpcd 2 */
-@@ -243,6 +369,9 @@
+@@ -243,6 +361,9 @@
default:
d-nsectors=40;
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fix for WINE on -CURRENT
Hello! On Mon, Nov 03, 2003 at 11:14:03PM -0600, Scot W. Hetzel wrote: Below is a patch to fix WINE for the new ATA driver. I created this patch based on the ideals from a previous user who had patched 3 other ports to work with -CURRENT's new ATA driver. Could someone familar with the new ATA driver have a look at this patch to make sure it is correct. can you make a patch for cdparanoia as well? cdparanoia is also broken on recent -CURRENT and testing will be easy. /fjoe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
make buildworld TARGET_ARCH=foobar seems to be broken
hi, there! Seems that for some reason gengenrtl is not built when doing 'make build-tools' in gnu/usr.bin/cc/cc_tools. As a result 'make buildworld TARGET_ARCH=foobar' is broken. Below is the output of 'make buildworld TARGET_ARCH=alpha' of recent HEAD on 4.7-STABLE/i386 === gnu/usr.bin/cc/cc_tools cc -O -pipe -mcpu=ev4 -mtune=ev5 -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/usr/obj/alpha/usr/fbsd/HEAD/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/fbsd/HEAD/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/fbsd/HEAD/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/fbsd/HEAD/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -static -DGENERATOR_FILE-c /usr/fbsd/HEAD/contrib/gcc/gengenrtl.c cc -O -pipe -mcpu=ev4 -mtune=ev5 -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/usr/obj/alpha/usr/fbsd/HEAD/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/fbsd/HEAD/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/fbsd/HEAD/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/fbsd/HEAD/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -static -DGENERATOR_FILE -o gengenrtl gengenrtl.o -O -pipe -mcpu=ev4 -mtune=ev5 -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/usr/obj/alpha/usr/fbsd/HEAD/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/fbsd/HEAD/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/fbsd/HEAD/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/fbsd/HEAD/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -static -DGENERATOR_FILE -o gengenrtl gengenrtl.o ./gengenrtl genrtl.c ./gengenrtl: 6: Syntax error: ) unexpected *** Error code 2 Stop in /usr/fbsd/HEAD/gnu/usr.bin/cc/cc_tools. *** Error code 1 Stop in /usr/fbsd/HEAD/gnu/usr.bin/cc. *** Error code 1 Stop in /usr/fbsd/HEAD/gnu/usr.bin. *** Error code 1 Stop in /usr/fbsd/HEAD/gnu. *** Error code 1 Stop in /usr/fbsd/HEAD. *** Error code 1 Stop in /usr/fbsd/HEAD. *** Error code 1 Stop in /usr/fbsd/HEAD. Running file in object directory shows the following: [EMAIL PROTECTED]:/usr/obj/alpha/usr/fbsd/HEAD/gnu/usr.bin/cc/cc_tools$file gen* | grep '^gen[a-z]*:' genattr:ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, not stripped genattrtab: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, not stripped [...] gengenrtl: ELF 64-bit LSB executable, Alpha (unofficial), version 1 (FreeBSD), statically linked, not stripped [...] genrecog: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, not stripped By the way why gengenrtl is executed at all? [EMAIL PROTECTED]:/usr/obj/alpha/usr/fbsd/HEAD/gnu/usr.bin/cc/cc_tools$./gengenrtl ./gengenrtl: Exec format error. Binary file not executable. [EMAIL PROTECTED]:/usr/obj/alpha/usr/fbsd/HEAD/gnu/usr.bin/cc/cc_tools$env FOO=bar ./gengenrtl ./gengenrtl: 6: Syntax error: ) unexpected (the shell is tcsh) /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: netncp/nwfs is rotting...
hi, there! On Mon, Feb 24, 2003 at 10:20:28PM -0800, Tim J. Robbins wrote: j A few months ago there was a thread on this list discussing the state of NWFS/netncp/libncp/etc. on 5.0. Terry Lambert produced a patch [1] that made netncp compile. The patch still applies cleanly to -current and almost compiles; I broke it with ncp_ncp.c rev 1.13, adding #includes of sys/lock.h and sys/mutex.h fixes it. However, even with this patch, ncp.ko still does not load because the aout_sysvec symbol is not available. After patching ncp_load() to use SYS_MAXSYSCALL instead of elf_sysvec.sv_size, the module loads but crashes in ncp_timer(): ncp_load: [210-213] Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x8:0xc1027d39 stack pointer = 0x10:0xc5b9cc8c frame pointer = 0x10:0xc5b9cc9c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, IOPL = 0 current process = 12 (swi6: clock) Even after that has been fixed, there are plenty of other bug fixes that need to be backported from smbfs. Is anyone still working on updating netncp/nwfs for 5.0? I think that it should be retired to the Attic if nobody has any plans to fix it before we create the RELENG_5 branch. I have a patch that makes nwfs work to some extent (i.e. I was able to mount and use netware shares from mars_nwe server). /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: error in nsdispatch.c
hi, there! On Tue, Feb 11, 2003 at 07:37:31PM -0600, David Leimbach wrote: There is a potential bug in src/lib/libc/net/nsdispatch.c in the function const ns_dbt * _nsdbtget(const char * name). The static variable static time_t confmod; is not initialized to anything. It may have some random value the first time this function is called and if you look at the program logic its the first value tested as well and it controls a lot of deallocation via free. Bug? no. static variables are initialized with all-zeroes. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
incremental cross-builds
hi, there! Is it possible to build a part of (for example) 5.x tree on 4.x machine? Suppose I have run make buildworld once, have bootstrap toolchain in /usr/obj and want to rebuild only libc. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: add ext2fs to the module list in modules/Makefile
hi, there! On Tue, Jan 28, 2003 at 12:40:12AM +0200, Enache Adrian wrote: On Mon, Jan 27, 2003 at 01:36:35PM -0800, Steve Kargl wrote: Portions of the ext2fs source are covered by the GPL. You need to rebuild the kernel with option EXT2FS. The FreeBSD cannot create a ext2fs.ko and comply with the GPL. This is weird. Builting it as part of kernel is ok, but separate, as a module isn't. IIRC NetBSD has BSD-copyrighted ext2fs implementation /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: add ext2fs to the module list in modules/Makefile
hi, there! On Mon, Jan 27, 2003 at 07:05:45PM -0800, David Schultz wrote: Portions of the ext2fs source are covered by the GPL. You need to rebuild the kernel with option EXT2FS. The FreeBSD cannot create a ext2fs.ko and comply with the GPL. This is weird. Builting it as part of kernel is ok, but separate, as a module isn't. IIRC NetBSD has BSD-copyrighted ext2fs implementation Closely tied to their VFS implementation, which is different, of course, last I heard it was a fairly heavy task to port it, but something a lot of people would like to see. Does it work any better/worse than FreeBSD's implementation? I've heard that their implementation is more stable and bug-free. Just a speculation though. Never had a time to look at it. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stand/sysinstall changes?
hi, there! On Thu, Jan 23, 2003 at 08:04:30AM -0800, Elden Fenison wrote: According to the handbook's instructions, back on 4.7 I used to always do the following as part of my installworld: cd /usr/src/release/sysinstall make all install This apparently updates the sysinstall stuff. With 5.0, I don't seem to have that directory any more. What happened to it?... is it obsolete? Is there a new way of doing this? How about my /stand directory, can I delete it? I did just upgrade from 4.7 to 5.0... and I'm thinking if I'm on 5.0, the old 4.7 /stand/sysinstall is probably pretty worthless to me. in 5.0 sysinstall is located in /usr/sbin and is therefore automatically updated after make world /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: only root can startx
hi, there! On Thu, Jan 23, 2003 at 12:37:55PM -0600, Charlie ROOT wrote: See /usr/ports/x11/wrapper. I have wrapper installed lorax# pkg_info | grep wrapper fampp-1.1 A C++ wrapper for fam from SGI gtkmm-1.2.8_1 C++ wrapper for gtk, a x11 graphics library javavmwrapper-1.4 Wrapper script for various Java Virtual Machines p5-File-Rsync-0.20 Perl convenience wrapper for the rsync(1) program wrapper-1.0_2 Wrapper for XFree86-4 server do I need to re-buildit? yes /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pw
hi, there!
Can we enable using '$' in usernames in pw?
The patch is attached.
Other variant is to enable using '$' only at end of user name.
/fjoe
Index: pw_user.c
===
RCS file: /home/ncvs/src/usr.sbin/pw/pw_user.c,v
retrieving revision 1.51
diff -u -p -r1.51 pw_user.c
--- pw_user.c 24 Jun 2002 11:33:17 - 1.51
+++ pw_user.c 23 Jan 2003 20:01:46 -
@@ -1195,7 +1195,7 @@ char*
pw_checkname(u_char *name, int gecos)
{
int l = 0;
- char const *notch = gecos ? :!@ : ,\t:+#%$^()!@~*?=|\\/\;
+ char const *notch = gecos ? :!@ : ,\t:+#%^()!@~*?=|\\/\;
while (name[l]) {
if (strchr(notch, name[l]) != NULL || name[l] ' ' || name[l] == 127
||
Re: pw
hi, there! On Thu, Jan 23, 2003 at 03:54:18PM -0500, Craig Rodrigues wrote: Can we enable using '$' in usernames in pw? The patch is attached. The same patch was submitted here by David Chapman: http://www.freebsd.org/cgi/getmsg.cgi?fetch=1059329+1062195+/usr/local/www/db/text/2002/freebsd-current/20021201.freebsd-current See the long discussion thread that followed. most messages were related to adduser.pl. adduser.pl has gone and adduser.sh now uses pw directly as for login class and group names -- there is nothing wrong with '$' in them but if anyone would be uncomfortable with it why not commit the patch that someone (Terry?) suggested that filters out '$' from login class and group names? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck did not create lost+found
hi, there! On Wed, Jan 22, 2003 at 07:18:44PM +0100, Jan Srzednicki wrote: Would that be a big problem to allow some fsck option not to erase all these softupdates-pending inodes, but to put them in lost+found as usual? It certainly couldn't be done with the background fsck, because background fsck works on a snapshot and not the running filesystem; thus, it cannot make any allocations -- it can only deallocate things. Still, in case you know some of your important files can be lost, you can boot the system to single user and run foreground fsck. this is not an option if the system was rebooted because of power loss or kernel panic /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck did not create lost+found
hi, there! On Wed, Jan 22, 2003 at 02:43:37PM -0500, Garance A Drosihn wrote: Would that be a big problem to allow some fsck option not to erase all these softupdates-pending inodes, but to put them in lost+found as usual? It certainly couldn't be done with the background fsck, because background fsck works on a snapshot and not the running filesystem; thus, it cannot make any allocations -- it can only deallocate things. Still, in case you know some of your important files can be lost, you can boot the system to single user and run foreground fsck. this is not an option if the system was rebooted because of power loss or kernel panic Can't you just set the rc.conf option to not-do the background fsck? I can but the whole purpose of background fsck (faster startup times) will be lost. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nVidia opengl works as root but not as user
hi, there! On Sun, Jan 05, 2003 at 12:31:56PM -0500, Jonah Sherman wrote: Im not sure why this would cause it but it's the only thing I can think of that differentiates between root and non-root for gl stuff: In your XF86Config-4, do you have a section which resembles the following? : Section DRI Mode 0666 EndSection If not, try adding it... Seems that nVidia OpenGL does not use DRI and nVidia drivers do not implement it. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CVS broken? (buildworld fails when cleaning tar)
hi, there! On Thu, Dec 05, 2002 at 01:43:38PM +0300, Denis N. Peplin wrote: I'm trying this: # cd /usr # rm -rf src obj # cvs -R co src use co -P (prune empty directories). Thanks, i will use it. But two weeks ago building world was succeseful w/o any additional options to cvs... -P is not an additional option. You should always use -P (put it into your ~/.cvsrc). This is how cvs directory removals are handled in cvs. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
hi, there! On Tue, Nov 05, 2002 at 12:12:45AM -0800, Terry Lambert wrote: Ok, I put the patch and test program to http://people.freebsd.org/~fjoe/libdl.tar.bz2. Patches are made against RELENG_4 (and all tests were done on RELENG_4) but it will not be that hard to port everything to -CURRENT. This is just a proof-of-concept work-in-progress. The plan is to add this stuff (rtld sources with -DLIBDL) to libc.a so statically linked programe will have dlopen/dlsym etc. I have some similar patches; the main difference is that mine are actually a standalone library. It utilizes the .init section to cause the initialization to take place normally, as per a standard constructor. standalone library will be harder to use. if you will name it libdl then all configure scripts will find it and will link with it (even in dynamically linked case). the only way I see is to include dlopen and friend to static version of libc OR move dlopen and friends to libdl from rtld-elf. Right now, my patches don't work with C++ because the replace the .init section. I have a modified version that actually uses the constructor list in the standard .init section, instead. can you show me an example of non-working program in C++? The main issue is the initialization of crt.crt_bp (normally, this is done via _callmain). The problem is that in calling __do_dynamic_link(), the argv argument is NULL in the constructor case. Basically, this means that the constructor code has to be modified to pass it in to each initially constructed object... the constructor has to change from a void to a void *, which most constructors ignore, for it to work. This is also a requirement, if you want the loaded shared obects that resolve external symbol references to symbols defined by the binary (e.g. as if they were dlopen'ed by a dymanically linked binary). that is hardly needed for nsswitch. btw libdl in Linux also is not able to resolve external symbols refs to symbols defined in main (statically linked) object. - gdb support for shared objecject dlopened from statically linked program is broken This is because of the argv, which is really the startup frame base address, which contains that information; it's not being initialized in the case where you're calling it. You really need to modify the crt0 code, and duplicate the dlopen mappings in a libdlopen, instead of modifying ld.so. - rtld_exit() is not called on exit so fini functions are not called on exit I had the same problem; mine came from stealing the section entry; the way to deal with this is to map the base frame so you can add an internal .fini traversal function to the atexit(). This has to be done in a reversible way, so you can't actually use atexit(3) itself to do the job. I think I can call atexit(rtld_exit) in rtld_init() - probably more stuff could be #ifdef'ed out from rtld when it is compiled with -DLIBDL I don't think so, actually. The question is how the symbols get in, in the first place. this is not high-priority task - xmalloc and friends names in rtld sources probably should be prepended with an underscore to prevent name clashes (if this stuff will be included in libc.a) You can actually deal with this by forcing the load of libc.so, the first time the dlopen() itself is called, if it's not loaded already, so the symbols will be available. It's ugly, but it works, in lieu of linking all .so's that make libc calls against libc.so (like you'd reasonably expect). this is not needed. malloc and friends will be linked from libc.a I am talking about xmalloc and firends which are used in rtld-elf internally. /fjkoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
hi, there! On Tue, Nov 05, 2002 at 12:08:33PM -0500, Jake Burkholder wrote: The plan is to add this stuff (rtld sources with -DLIBDL) to libc.a so statically linked programe will have dlopen/dlsym etc. Problems with current patches are: - I do not know what to do on alpha with _GOT_END_ and _GLOBAL_OFFSET_TABLE_ symbols. I had to use ld.so.script to solve missing _GOT_END_ problem and ifdef out _GLOBAL_OFFSET_TABLE_ usage from alpha/reloc.c for second problem. An advice from alpha rtld guru will be very useful - gdb support for shared objects dlopened from statically linked program is broken - rtld_exit() is not called on exit so fini functions are not called on exit - probably more stuff could be #ifdef'ed out from rtld when it is compiled with -DLIBDL - xmalloc and friends names in rtld sources probably should be prepended with an underscore to prevent name clashes (if this stuff will be included in libc.a) Any comments, suggestions, patches will be very appreciated. I think there are more problems than you realize. They are very hard to fix. You've basically hacked rtld to bits. All the ifdefs make it hard to read and maintain. There number of #ifdef's is not large (for me) to make rtld unmaintainable. If this is inappropriate for you there are two obvious ways to solve it: - refactor rtld-elf and move common parts of libdl (or whatever) and rtld-elf to separate files - unifdef rtld-elf and put libdl sources separately The reasons I implemented this as a patch for rtld-elf are: - I did not want to create two almost identical pieces of code - I wanted to make these patches as obvious as they can be. This is just a proof-of-concept work. This statically links rtld into any static binary that wants to use dlopen. What was that about saving space on the root partition? I didn't tell you or anyone else that this work is done towards saving space in /. The question was about nsswitch and (in particular) dlopen in statically linked programs. The only way to save space in / and to be able to use nsswitch is make everyhting shared exactly like NetBSD did a few weeks ago. I saw a number of complaints about loosing an ability to repair system if something goes wrong. I guess that people just haven't looked at what NetBSD folks have done. Yes, they have a number of statically linked programs in /rescue. Yes, they have created /lib. -rwxr-xr-x 1 jake wheel 143177 Nov 5 11:57 hello This is more than twice as big as a normal static binary which just calls printf on my system. ~90K bloat just for dlopen. This is the price you pay for dlopen. This is how things are in other systems that are capable of using dlopen in statically linked executables. I don't see that you've dealt with getting the linker to generate the tables that rtld needs; an _DYNAMIC section, a dynsym table, a dynstr table etc. These are needed in order to look up symbols in the statically linked binary itself. Getting the linker to do this is not overly difficult, we do it for the kernel, but it bloats the static binaries more. I do not have Solaris at hand but Linux is not capable of resolving symbols refs in shared objects to main binary. This is not even possible at all. At a time of static linking ld can not know which symbols will supposedly loaded shared library need. Will it need fopen()? Will it need fts_open()? In Linux libdl implementation you can't also use dlopen(NULL,...) in main program. It also creates a special case in the makefiles, unless we do this for all static binaries, which would cause a lot of bloat. Are you talking about STATICOBJS and SHOBJS? This is how libpam is built right now. You have different sets object files in shared and static versions of libpam. Please take a look at src/lib/libpam/libpam/Makefile and corresponding /usr/share/mk bits. As a result of the above, how do you deal with multiple implementations of library services being present? For example a statically linked binary calls malloc, so it has a copy of malloc linked into it. It tries to dlopen a library which also calls malloc. Which copy of malloc does the library use? How does it locate the malloc that's linked into the static binary without the dynamic tables? A part of answer is above (about ld not knowing which symbols shared object will want). The real solution is to link shared libraries with all objects they will need (including libc). This is how things are implemented in other systems. As a result library will use malloc from libc that will be loaded as a dependency (and this is demonstrated in the example I posted). What happens when the application tries to free a pointer allocated by the library, or vice versa? This is not possible for obvious reasons. On Linux you will get SEGFAULT (for the same obvious reasons). Yes, this is a limitation. When David said we didn't think it could be done properly or sanely, we meant it. It must
Re: libc size
hi, there! On Wed, Nov 06, 2002 at 12:20:50AM +0600, Max Khon wrote: The only way to save space in / and to be able to use nsswitch is make everyhting shared exactly like NetBSD did a few weeks ago. I saw a number of complaints about loosing an ability to repair system if something goes wrong. I guess that people just haven't looked at what NetBSD folks have done. Yes, they have a number of statically linked programs in /rescue. Yes, they have created /lib. I was not 100% correct there. I know about a idea to use a daemon (for NSS) that listens on unix domain socket but that would not save space either because you had to have fallbacks in libc anyway (for case when this daemon is not running). -rwxr-xr-x 1 jake wheel 143177 Nov 5 11:57 hello This is more than twice as big as a normal static binary which just calls printf on my system. ~90K bloat just for dlopen. This is the price you pay for dlopen. This is how things are in other systems that are capable of using dlopen in statically linked executables. I don't see that you've dealt with getting the linker to generate the tables that rtld needs; an _DYNAMIC section, a dynsym table, a dynstr table etc. These are needed in order to look up symbols in the statically linked binary itself. Getting the linker to do this is not overly difficult, we do it for the kernel, but it bloats the static binaries more. I do not have Solaris at hand but Linux is not capable of resolving symbols refs in shared objects to main binary. I need to add (aside from what I told in previous letter) that requirement for libdl to build _DYNAMIC section means changes to binutils (because there is no information in statically linked executable which libdl can use to build such section). I think this is not the game anyone would like to play. By the way, space bloat is not that large: fjoe@husky:~$ls /bin /sbin | wc -l 132 fjoe@husky:~$ Some of that programs are hard-linked and some of them do not use getXXXbyYYY functions (or call other functions that use getXXXbyYYY, like user_from_uid). The bloat will be about 10M in worst case and this is quite appropriate before we switch to shared / Of course, there should be NO_NSS knob for libc for embedded environments. I do not consider my work as something that FreeBSD badly needs and do not insist on getting it right now as is (yes, it needs some polishing and maybe not everything works as expected, yes there are some obvious limitations in using dlopen from statically linked programs), but I think it removes some of limitations we currently have. Yet another example of stuff that (I think) we need to have in libc and which uses dlopen is Citrus Project (I18N Framework). /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
hi, there!
On Tue, Nov 05, 2002 at 03:27:57PM -0500, Jake Burkholder wrote:
Are you talking about STATICOBJS and SHOBJS? This is how libpam is built
right now. You have different sets object files in shared and static
versions of libpam. Please take a look at src/lib/libpam/libpam/Makefile
and corresponding /usr/share/mk bits.
What I was referring to is a trick to force the linker to generate
a dynamic binary with all the usual elf dynamic tables, but which is
actually statically linked.
eg:
cat test.c
int
main(void)
{
printf(hello world\n);
}
cc -static -Wl,-r -o test test.c
touch hack.c
cc -shared -o hack.So hack.c
ld -o test1 test /home/jake/hack.So
./test1
hello world
Conceivably this would allow dlopen to work on the main program, and is
what we do to allow the kernel to link klds against itself. But you
also need to do something about the .interp section that gets put in,
and the .dynamic, .dynsym and .dynstr sections aren't free.
Got it. But this will not solve the problem. All the symbols
in statically linked executable are resolved at linking stage
and there is no information in it that libdl can use in find_symdef()
(if we strip the executable. Do we want unstripped executables?).
Patching binutils is not easy and I doubt that someone would like to do this.
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: libc size
hi, there! On Mon, Nov 04, 2002 at 01:57:35PM -0800, David O'Brien wrote: another 2.4M for /rescue. That makes it less impressive. I don't find the duplication appealing, either. (Why not just put the /rescue versions directly into /bin and /sbin? That would be smaller still, Because that would nullify one of the big reasons for making /bin and /sbin shared -- so one can dlopen(3). We can't, for instance, get a proper nsswitch implementation until we make /bin and /sbin dynamic. Before someone says you can dlopen() from static binaries in order to implement nsswitch, please provide the patch proving it. Our best FreeBSD minds don't think it can be done properly and sanely. I have the patch. Currently it is made against RELENG_4 and I have a couple of questions about alpha (however it works on alpha too with a few hacks). Unfortunately, jdp does not have enough time to review it and I have lack of time to port it to -current (that would not be that hard but since sparc64 is now Tier-1 platform the patch should be ported to sparc64 too but I do not have sparc64 hardware and access to panther is very slow from my home). What is the right place to post the patch and test program demonstrating dlopen for statically linked programs? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
hi, there! On Tue, Nov 05, 2002 at 02:18:23AM -0500, Jake Burkholder wrote: Before someone says you can dlopen() from static binaries in order to implement nsswitch, please provide the patch proving it. Our best FreeBSD minds don't think it can be done properly and sanely. I have the patch. Currently it is made against RELENG_4 and I have a couple of questions about alpha (however it works on alpha too with a few hacks). Unfortunately, jdp does not have enough time to review it and I have lack of time to port it to -current (that would not be that hard but since sparc64 is now Tier-1 platform the patch should be ported to sparc64 too but I do not have sparc64 hardware and access to panther is very slow from my home). What is the right place to post the patch and test program demonstrating dlopen for statically linked programs? Put it up somehere on the web or email it to the list. I'd be interested in looking at it. Ok, I put the patch and test program to http://people.freebsd.org/~fjoe/libdl.tar.bz2. Patches are made against RELENG_4 (and all tests were done on RELENG_4) but it will not be that hard to port everything to -CURRENT. This is just a proof-of-concept work-in-progress. The plan is to add this stuff (rtld sources with -DLIBDL) to libc.a so statically linked programe will have dlopen/dlsym etc. Problems with current patches are: - I do not know what to do on alpha with _GOT_END_ and _GLOBAL_OFFSET_TABLE_ symbols. I had to use ld.so.script to solve missing _GOT_END_ problem and ifdef out _GLOBAL_OFFSET_TABLE_ usage from alpha/reloc.c for second problem. An advice from alpha rtld guru will be very useful - gdb support for shared objects dlopened from statically linked program is broken - rtld_exit() is not called on exit so fini functions are not called on exit - probably more stuff could be #ifdef'ed out from rtld when it is compiled with -DLIBDL - xmalloc and friends names in rtld sources probably should be prepended with an underscore to prevent name clashes (if this stuff will be included in libc.a) Any comments, suggestions, patches will be very appreciated. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
hi, there! On Thu, Oct 31, 2002 at 12:39:10AM -0800, David O'Brien wrote: Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. Huh? Your statement is rather speculative stuff. Other systems (say Linux) are using the same linker we are. Please speculate less. Please grab an older ld and try to prove your speculation. I think the problem is in our dynamic linker or in the way we link dynamic libraries or in the way we compile and link X11 libraries. Linux also has pthreads symbols weakly defined (some of them are defined in glibc, some of them in libpthread) and does not have such problems. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
building -CURRENT on RELENG_4
hi, there! cross-building -CURRENT on RELENG_4 is broken in src/usr.bin/xlint/lint1: --- cut here --- ... sh /usr/fbsd/HEAD/src/usr.bin/xlint/lint1/makeman /usr/libexec/lint1 -m lint.7 lint1: illegal option -- m usage: lint1 [-abcdeghprstuvyzF] src dest gzip -cn lint.7 lint.7.gz --- cut here --- /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pkg-comment
hi, there!
On Mon, Aug 12, 2002 at 12:36:51PM -0700, David O'Brien wrote:
Since pkg-comment contains only a single line, wouldn't it be more subtile
to put it in a COMMENT field as does NetBSD, instead of using a file? I think
it would speed up updates.
http://people.FreeBSD.org/~eric/ports-comment.diff
Will Andrews said that portmgr would be going over this sometime soon,
hopefully they will commit it.
That will certainly be a big help. When we got rid of the pkg/ and
patches/ directories I begged Satoshi to go farther and put patches in
main port directory and get rid of pkg/COMMENT. That was back when we
hit 3000 ports -- I guess people didn't want to accept we would hit 8000
in only a few years.
Of course why we don't just put COMMENT=blah in the ports's Makefile
Posted patch uses `head -1 ${DESCR}` however.
I'd prefer to go NetBSD way and use COMMENT=blah for ports comments
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: openoffice is compiling again!...but won't run.
hi, there! On Fri, Jul 12, 2002 at 01:30:47AM +0200, Martin Blapp wrote: Make sure you use the ports gcc31 for compiling. The c++ from CURRENT has broken exception handling. In the next few days a patch will be committed to address this. btw does it still use -fsjlj method for exception handling? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 ATA is very broken after sparc64 ATA mega-commit (April 5)
hi, there! On Thu, Apr 18, 2002 at 01:51:19AM -0700, Doug Barton wrote: It seems Doug Barton wrote: Given the impending 4.6-release, might it make sense to back off ata in The busdma/sparc64 code is *not* in stable... Hmmm... I thought I saw some complaints on -stable, but I might have been mistaken. tagged queuing is broken in RELENG_4 too /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problem with ssh
hi, there! On Thu, Mar 28, 2002 at 11:43:58AM -0800, Julian Elischer wrote: On Thursday 28 March 2002 10:28 am, Michael L. Hostbaek wrote: Beech Rintoul (akbeech) writes: 'ChallengeResponseAuthentication no' Thanks, that fixed the problem. just stops my sshd from working at all. (machine is 4.1.1) I guess this config option was named differently in earlier sshd versions (SKeyAuthentication or something like that) /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
hi, there! On Thu, Feb 28, 2002 at 09:58:00PM +0100, Søren Schmidt wrote: Hmm, why do we need to add new layers and loss of functionality to the ATAPI devices ? Many many many people would like to be able to use cdrecord to burn data to cd's so that all the front-ends to cdrecord will work. It's much nicer than memorizing mkisofs commandline switches :-) Hmm, cdrecord can be used with the ATAPI sunsystem as it is, I did patches for this long ago, but noone picked it up as a port... what about cdrdao? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why isn't PAM_smb available for FreeBSD?
hi, there! On Sat, Feb 16, 2002 at 01:14:11AM -0800, Terry Lambert wrote: According to the pam_smb webpage, it states that it works cleanly with FreeBSD 3.x onwards, so I will have to try it out anyway. BTW, what is NSS? Network Security Services; supposedly it's required, according Name Service Switch to the web page where you grab pam_smb from, but that could just be because of the WINS name services. I don't run a large enough Windows network to see the problem (I don't run a WINS server at all, nor a domain controller/ master browser). /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FW: Re: windbindd
hi, there! On Wed, Feb 13, 2002 at 03:55:28AM -0800, Terry Lambert wrote: Is there any way to impliment dl_open in our nsswitch for -current so that samba's winbindd can work on FreeBSD? no. It's actually not that hard to write a libdlopen that mmap's exectuable the ld.so itself, and then does manual lookup of the dl entry points, providing symbols for them which are actually externed functions wrapping dereferenced function pointers. It's just that no one has bothered to do the work, yet, for FreeBSD (other OSs have it). are you talking about dlopen in statically linked binaries? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
hi, there! On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: So what? Just because it wasn't part of 4.2 BSD, does that mean that we should never support it? 2. What is so hard with installing the port. No one has answered *THAT* question yet. Ports are installed in /usr/local. gcc is installed in /usr. Either provide a way to install *all* of gcc as part of the system, or provide a *suppported* way to *replace* it with a port. I do not want to have two versions of gcc fighting for disk space and confusing users over PATH issues. please calm down. seems that you have never installed gcc from ports. gcc 2.95 from ports is installed as gcc295/g++295 and correctly gets its bits from /usr/local/lib/gcc-lib/xxx, gcc 3.0x from ports is named gcc30/g++30 and so on. There is no PATH issue. Switching between compilers is as easy as setting correct CC/CXX environment/Makefile variables. argument about disk space sounds a bit funny these days. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Support for atapi cdrw as scsi in -current?
hi, there! On Tue, Feb 05, 2002 at 08:14:22PM +0100, Thomas Quinot wrote: Is there a place where I can find this updated patch which will work for me in the current -current? Thanks. I put up updated patches at http://www.cuivre.fr.eu.org/~thomas/atapicam/ For -CURRENT, you should be using the latest one (of today) which fixes a silly line inversion. I'd be very interested in success/failuire reports on this patch, especially with ATAPI tape or floppy drives. I successfully recorded data cd using cdrecord on NEC NR-7700A IDE CD-RW. dmesg follows Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.5-STABLE #0: Thu Feb 7 04:49:06 NS 2002 [EMAIL PROTECTED]:/usr/obj/usr/fbsd/RELENG_4/src/sys/husky Timecounter i8254 frequency 1193182 Hz CPU: AMD-K7(tm) Processor (503.53-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x612 Stepping = 2 Features=0x81f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX AMD Features=0xc040AMIE,DSP,3DNow! real memory = 268369920 (262080K bytes) config enable apm0 config quit avail memory = 256040960 (250040K bytes) Preloaded elf kernel kernel at 0xc04af000. Preloaded userconfig_script /boot/kernel.conf at 0xc04af09c. Preloaded elf module if_ppp.ko at 0xc04af0ec. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 7 entries at 0xc00f82b0 apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface pcib0: AMD-751 host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: AMD-751 PCI-PCI (1x/2x AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: NVidia Riva Ultra Vanta TNT2 graphics accelerator at 5.0 irq 11 isab0: VIA 82C686 PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA66 controller port 0xffa0-0xffaf at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xcc00-0xcc1f irq 12 at device 4.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xd000-0xd01f irq 12 at device 4.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered chip1: VIA 82C686 ACPI interface at device 4.4 on pci0 pci0: unknown card (vendor=0x1274, dev=0x1371) at 13.0 irq 11 ed0: NE2000 PCI Ethernet (RealTek 8029) port 0xc400-0xc41f irq 5 at device 14.0 on pci0 ed0: address 00:00:01:00:fb:08, type NE2000 (16 bit) sym0: 810a port 0xd800-0xd8ff mem 0xef00-0xefff irq 10 at device 15.0 on pci0 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking orm0: Option ROMs at iomem 0xc-0xc,0xd-0xd3fff on isa0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 IP packet filtering initialized, divert enabled, rule-based forwarding disabled, default to deny, logging disabled ad0: 9671MB IBM-DTTA-351010 [19650/16/63] at ata0-master UDMA33 acd0: CD-RW _NEC NR-7700A at ata1-master using PIO4 (noperiph:atapi1:0:-1:-1): Registered SIM for ata1 Waiting 15 seconds for SCSI devices to settle atapicam1m: read data overrun 96/95 Mounting root from ufs:/dev/ad0s2a cd1 at atapi1 bus 0 target 0 lun 0 cd1: _NEC NR-7700A 1.01 Removable CD-ROM SCSI-0 device cd1: 3.300MB/s transfers cd1: cd present [347816 x 2048 byte records] cd0 at sym0 bus 0 target 6 lun 0 cd0: SONY CD-R CDU948S 1.0e Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 8) cd0: cd present [327225 x 2048 byte records] pcm0: AudioPCI ES1373-8 port 0xc800-0xc83f irq 11 at device 13.0 on pci0 /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Support for atapi cdrw as scsi in -current?
hi, there! On Thu, Feb 07, 2002 at 12:38:08PM +0100, Søren Schmidt wrote: I put up updated patches at http://www.cuivre.fr.eu.org/~thomas/atapicam/ For -CURRENT, you should be using the latest one (of today) which fixes a silly line inversion. I'd be very interested in success/failuire reports on this patch, especially with ATAPI tape or floppy drives. I successfully recorded data cd using cdrecord on NEC NR-7700A IDE CD-RW. dmesg follows Doesn't burncd work for you on -current ? I tried burncd in -stable. it works for me. but with ATAPI CAM stuff you get access to a whole bunch of neat cd recording and cd ripping tools (e.g. cdrdao) I haven't tried DAO with burncd in -current (I haven't tried DAO with ATAPI CAM stuff too but I'll try to find spare time this week to test it, I do not even know if cdrdao supports my drive). /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
hi, there! On Wed, Feb 06, 2002 at 02:52:40PM -0500, Mikhail Teterin wrote: But alright, let's say -- ports. gcj and gcjh themselves are installed by the several lang/gcc* ports, but they are not functional (libgcj/libjava are not ported). As a ports committer I might try to fix that, but I think, those ports should complement the base system, and that the base system should provide the bits it already uses itself (like libbfd and libiberty) to the programmers, that use FreeBSD -- install them into /usr/lib and link them _dynamicly_ into the tools. dynamically linked libiberty would be a nightmare. libbfd anf libiberty do not have version numbers, are not maintained (i.e. there is no official releases). every project includes its own libiberty and imho an attempt to find least common denominator will fail /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
hi, there! On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: So what? Just because it wasn't part of 4.2 BSD, does that mean that we should never support it? 2. What is so hard with installing the port. No one has answered *THAT* question yet. Ports are installed in /usr/local. gcc is installed in /usr. Either provide a way to install *all* of gcc as part of the system, or provide a *suppported* way to *replace* it with a port. I do not want to have two versions of gcc fighting for disk space and confusing users over PATH issues. please calm down. seems that you have never installed gcc from ports. gcc 2.95 from ports is installed as gcc295/g++295 and correctly gets its bits from /usr/local/lib/gcc-lib/xxx, gcc 3.0x from ports is named gcc30/g++30 and so on. There is no PATH issue. Switching between compilers is as easy as setting correct CC/CXX environment/Makefile variables. argument about disk space sounds a bit funny these days. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs support
hi, there! On Fri, Dec 28, 2001 at 09:33:08PM +0100, Jan Stocker wrote: What is the state of smbfs for current at present? Boris Popov has updated kernel-side smbfs for KSE. Sheldon Hearn imported smbfs 1.4.3 userland (to both HEAD and RELENG_4). smbfs should work out of box. we still do not have libiconv in base system so if you want to do filenames recoding you have to install it from ports. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs support
hi, there! On Wed, Nov 28, 2001 at 02:30:54PM +0200, Sheldon Hearn wrote: | I'm trying to compile smbfs. I've added SMBFS and NETSMB options to my kernel | config, but I'm not sure is it enough. The output of make buildkernel is as | follows: I don't think anyone's updated smbfs for the post-KSE world order. The smbfs maintainer seems snowed under, and Julian wants someone who understands it better to take a look. That was the case a couple of weeks ago, at any rate. I have some untested patches in my tree and I will contact bp this week about them (I wanted to import smbfs userland to the tree and already got ok from bp but could not test it because kernel-side smbfs is not compilable yet). /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs support
hi, there! On Wed, Nov 28, 2001 at 02:55:24PM +0200, Sheldon Hearn wrote: | I have some untested patches in my tree and I will contact bp this | week about them (I wanted to import smbfs userland to the tree and | already got ok from bp but could not test it because kernel-side smbfs | is not compilable yet). Excellent news! Presumably, if bp doesn't respond by the end of the year, you'll go ahead regardless? :-) :) bp is quite responsive. I even had a talk with him on #bsdcode /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: misc/15421 (was: Re: initgroups)
hi, there!
On Mon, Nov 19, 2001 at 06:19:50PM +0200, Ruslan Ermilov wrote:
Can setgroups return a positive number? If so, you've just changed
the semantics of the funtion; before, it used to return 0 on 0 or a
positive number.
No. setgroups() is a syscall, and as such returns either 0 or -1.
Also, is removing the _warn() really the only thing you want to
accomplish? It should probably be seperate.
I have intended to commit the below patch for almost a year now,
just haven't had enough time to actually fo it. NetBSD runs with
this fix since 1999.
Index: initgroups.c
===
RCS file: /home/ncvs/src/lib/libc/gen/initgroups.c,v
retrieving revision 1.4
diff -u -p -r1.4 initgroups.c
--- initgroups.c 2001/08/29 13:52:26 1.4
+++ initgroups.c 2001/11/19 16:16:11
@@ -56,12 +56,6 @@ initgroups(uname, agroup)
int groups[NGROUPS], ngroups;
ngroups = NGROUPS;
- if (getgrouplist(uname, agroup, groups, ngroups) 0)
- warnx(%s is in too many groups, using first %d,
- uname, ngroups);
- if (setgroups(ngroups, groups) 0) {
- _warn(setgroups);
- return (-1);
- }
- return (0);
+ getgrouplist(uname, agroup, groups, ngroups);
+ return (setgroups(ngroups, groups);
}
Index: initgroups.3
===
RCS file: /home/ncvs/src/lib/libc/gen/initgroups.3,v
retrieving revision 1.10
diff -u -p -r1.10 initgroups.3
--- initgroups.3 2001/10/01 16:08:51 1.10
+++ initgroups.3 2001/11/19 16:16:11
@@ -61,10 +61,14 @@ is automatically included in the groups
Typically this value is given as
the group number from the password file.
.Sh RETURN VALUES
+.Rv -std initgroups
+.Sh ERRORS
The
.Fn initgroups
-function
-returns \-1 if it was not invoked by the super-user.
+function may fail and set
+.Va errno
+for any of the errors specified for the library function
+.Xr setgroups 2 .
.Sh SEE ALSO
.Xr setgroups 2 ,
.Xr getgrouplist 3
ok
I asked tobez (he is an originator and he took responsibility on this PR)
and he said that src/ must be audited also -- he said that some initgroups()
callers do not print error message because initgroups() did this
previously.
I'll try to do this before this weekend and I will post combined patch
to audit@
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
initgroups
hi, there!
Any objections if I will commit the following patch (see PR/15421)?
Index: initgroups.c
===
RCS file: /home/ncvs/src/lib/libc/gen/initgroups.c,v
retrieving revision 1.4
diff -u -r1.4 initgroups.c
--- initgroups.c2001/08/29 13:52:26 1.4
+++ initgroups.c2001/11/13 20:17:03
@@ -59,9 +59,5 @@
if (getgrouplist(uname, agroup, groups, ngroups) 0)
warnx(%s is in too many groups, using first %d,
uname, ngroups);
- if (setgroups(ngroups, groups) 0) {
- _warn(setgroups);
- return (-1);
- }
- return (0);
+ return setgroups(ngroups, groups);
}
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?
hi, there!
Same here. My -CURRENT system is replying to those ARP request which carry
0.0.0.0 as sender IP address:
14:43:33.706099 arp who-has 158.227.48.193 (ff:ff:ff:ff:ff:ff) tell 0.0.0.0
14:43:33.706152 arp reply 0.0.0.0 is-at 0:d0:b7:3e:a0:fb
I think this is because I have an interface that is up and has NO IP
address:
I don't think so:
# ifconfig -a
fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 158.227.6.52 netmask 0xff00 broadcast 158.227.6.255
inet6 fe80::2d0:b7ff:fe3e:a0fb%fxp0 prefixlen 64 scopeid 0x1
inet6 fec0::9ee3:634 prefixlen 120
ether 00:d0:b7:3e:a0:fb
media: Ethernet autoselect (100baseTX full-duplex)
status: active
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff00
Something is broken in the ARP implementation of -CURRENT.
please try this patch (provided by jlemon)
Index: if_ether.c
===
RCS file: /ncvs/src/sys/netinet/if_ether.c,v
retrieving revision 1.85
diff -u -r1.85 if_ether.c
--- if_ether.c 2001/10/17 18:07:05 1.85
+++ if_ether.c 2001/10/19 15:38:07
@@ -593,10 +593,12 @@
isaddr.s_addr == ia-ia_addr.sin_addr.s_addr)
goto match;
/*
-* No match, use the first address on the receive interface
+* No match, use the first inet address on the receive interface
* as a dummy address for the rest of the function.
*/
- ifa = TAILQ_FIRST(ifp-if_addrhead);
+ TAILQ_FOREACH(ifa, ifp-if_addrhead, ifa_link)
+ if (ifa-ifa_addr ifa-ifa_addr-sa_family == AF_INET)
+ break;
if (ifa == NULL) {
m_freem(m);
return;
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?
hi, there! On Thu, Oct 18, 2001 at 12:00:52AM +0200, Jose M. Alcaide wrote: On Wed, Oct 17, 2001 at 12:11:45PM -0700, Julian Elischer wrote: I've seen this when DHCP fails to allocate an address. But I am not using DHCP. Maybe there are other machines in the LAN (it is a *big* LAN) trying to get their addresses using DHCP, and now -CURRENT shows a message whenever detects one of those packets. I will try to identify the senders (over 40!). Anyway, these 0.0.0.0 ARP messages are new in -CURRENT, and none of our machines running FreeBSD 4.x show them. how current -CURRENT are you running? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /usr/games/wtf
hi, there! I would like to add /usr/games/wtf from NetBSD to base system. Any opinions/objections? wtf is it? NAME wtf - translates acronyms for you SYNOPSIS wtf [is] acronym ... husky:~$wtf is pola POLA: principle of least astonishment husky:~$ /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
/usr/games/wtf
hi, there! I would like to add /usr/games/wtf from NetBSD to base system. Any opinions/objections? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
hi, there! On Tue, 17 Jul 2001, Garance A Drosihn wrote: Personally, I think it's worth it to get rid of a GNU dependency in the base system, as well as reducing the overall amount of functional code duplication. I may be misunderstanding what you mean here, but I don't think we should replace libreadline with libedit. However, I do find this very interesting, as some of my friends and I have a program that we're going to switch from gnu to bsd licensing, and it would be nice if we could use this libedit instead of libreadline. I read on pgsql-hackers mailinglist that only static linking with libreadline will infect your binaries with GPL virus. btw PostgreSQL already has support for NetBSD's libedit /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sysinstall and wrong /etc/ttys types
hi, there! On Fri, 11 May 2001, Andrey A. Chernov wrote: Look through the cvs history for sysinstall - you'll see that it already had much of that already, back around 2.0.5 I think. It was eventually removed again due to disuse. Could you please be more specific on what you mean by disuse? I.e. what was the problem with that stuff and what goes wrong? Do you against its resurrection by what reasons? having sysinstall that configures /etc/ttys will be great /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New threads way questions
hi, there! On Wed, 31 Jan 2001, Andrey A. Chernov wrote: I have some questions about new threads way. Daniel says that new way is: gcc -Wall -o foo foo.c -lc_r 1) What about libgcc_r.a? Is it picked automatically in this case or not? Is it ever needed now? we do not have libgcc_r.a in both -current and -stable anymore 2) Is new way is backward-compatible with old way? I.e. can we just change ports to use new way and assume that still works on -stable? no 3) Is -D_THREAD_SAFE required now? no /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem building -current kernel with read-only /usr/src.
hi, there! On Sat, 23 Dec 2000, Chris wrote: Actually, last time I checked, I think stable did not install with a RO /usr/src either. Anyone know if this is still the case? I have no problems with 'make installworld' with RO obj and src on latest -stable /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ABI is broken??
hi, there! On Wed, 1 Nov 2000, John Polstra wrote: Here are all the random facts which, when put together, explain what is going on. Your old application was (like all -pthread programs) linked with "/usr/lib/libgcc_r.a". That library contains a function "__register_frame_info" which uses some of the facilities of the pthreads library "libc_r". The pthreads library has to be initialized before it can be used, by a call to _thread_init. If some functions such as pthread_mutex_lock are called before the library has been initialized, a segmentation violation results. [...] Overall I would lean toward putting the hack into pthread_mutex_lock. Comments? do we still need uthread_autoinit.cc? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pw_class in _pw_passwd is null if __hashpw() is not called inprior
hi, there! On Thu, 28 Sep 2000, Dan Nelson wrote: Here is another possible trouble. While libc.so.4 with nsswitch no longer requires the magic '+' entry, libc.so.3 and earlier still require '+'. IMHO, This Is A Bug. Depends on what Seigo meant. If he meant that libc.so.4 and no /etc/nsswitch.conf implicitly adds a "+" to the end of /etc/passwd, that's definitely a bug. If he meant that libc.so.4 and an nsswitch.conf of "passwd: files nis" doesn't require a "+", that's fine. "passwd: compat" should require '+' if I understand it correctly /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Permissions for /var/mail
hi, there! On Sat, 23 Sep 2000, Leif Neland wrote: Pine 4.21 complains that /var/mail is vulnerable, that the perms should be 1777 Would this be less vulnerable than 775 which make world restores it to? this happens because ports/mail/pine4/patches/patch-aw was not merged when libc-client was moved to separate port /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gdb bug w/ dlopen()ed images
hi, there! On Fri, 25 Aug 2000, John DeBoskey wrote: There appears to be a problem with gdb when debugging dynamically loaded images. On 5.0-current with sources current and built as of this evenning and a 4.1-STABLE system, the following incorrect result is seen: PR/20373 Solution: apply patch 1.8-1.9 for bfd/elf32-i386.c from binutils source tree (their cvsweb is somewhere at http://sources.redhat.com/binutils/) to src/contrib/binutils/bfd/elf32-i386.c and rebuild src/gnu/usr.bin/binutils/libbfd and src/gnu/usr.bin/binutils/ld Unfortunately for some reason I cannot post follow-up for this PR. David O'Brien has all the information. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: crypt(3) problems
hi, there! On Tue, 8 Aug 2000, Brian Fundakowski Feldman wrote: We should switch to using just libdescrypt and being allowed to switch crypt formats easily between md5 and des. My proposed solution using login.conf is at http://people.FreeBSD.org/~green/crypt_switching.patch, and it's going to be put into production usage relatively soon (that is, whether or not it's actually in FreeBSD). this would solve a lot of problems with libcrypt for third-party software developers. at this time to ensure that our product will work on any FreeBSD installation we link libdescrypt statically (which is a pain in the ass if f.e. libtool is used) /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Updating our CVSweb
hi, there! On Wed, 2 Aug 2000, Akinori -Aki- MUSHA wrote: I have been hacking on CVSweb for a while and now I think it is the time we update our CVSweb to the full-featured version, which is based on Henner Zeller and other people's work. The ready-to-commit demo is available at this page: http://people.FreeBSD.org/~knu/cgi-bin/cvsweb.cgi/ maybe it is worth moving form that allows request diffs between any two revision to the top? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Updating our CVSweb
hi, there! On Wed, 2 Aug 2000, Akinori -Aki- MUSHA wrote: maybe it is worth moving form that allows request diffs between any two revision to the top? Well, following the hyperlink "Request diff between arbitrary revisions" will take you to the form. It's as easy as a single click. :) when you are loading file with a lot of revisions over slow link you can always stop transfer and use the form. that's the point. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ftp client bug
hi, there!
On Fri, 23 Jun 2000, Dmitry Valdov wrote:
There is a problem in ftp client in all FreeBSD versions. It isn't dangerous
but probably should be fixed.
uname -a
FreeBSD work.dv.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #6: Thu Jun 22 19:41:50
MSD 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/WORK i386
ftp localhost
Connected to localhost.
220 work.dv.ru FTP server (Version 6.00LS) ready.
Name (localhost:dv):
331 Password required for dv.
Password:
230 User dv logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp site %s
Segmentation fault (core dumped)
that's easy:
--- cmds.c.orig Fri Jun 23 20:12:24 2000
+++ cmds.c Fri Jun 23 19:58:19 2000
@@ -1461,7 +1461,7 @@
len += len1;
}
}
- if (command(buf) == PRELIM) {
+ if (command("%s", buf) == PRELIM) {
while (getreply(0) == PRELIM)
continue;
}
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ARP issues (Arcnet)
hi, there! Once again I'm trying to port Arcnet driver from NetBSD/amiga to FreeBSD/i386 (like I did more than a year ago for 3.x). The problem is in ARP stuff -- should I port if_arp.c from NetBSD or should I make changes in if_ether.c for arcnet stuff like Token Ring support did? Any suggestions are appreciated. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree 3.3.6 authentication failed?
hi, there! On Wed, 23 Feb 2000 [EMAIL PROTECTED] wrote: I am running monday's current, Mesa-glx for Riva, XFree 3.3.6 and KDE 1.1.2. All from monday's ports tree. Well, I think I can't say I am running this system, for I am getting the following message whenever I try startx: Authentication failed - cannot start X server. Perhaps you do not have console ownership? _X11TransSocketUNIXConnect: Can't connect: errno = 2 _X11TransSocketUNIXConnect: Can't connect: errno = 2 _X11TransSocketUNIXConnect: Can't connect: errno = 2 _X11TransSocketUNIXConnect: Can't connect: errno = 2 _X11TransSocketUNIXConnect: Can't connect: errno = 2 _X11TransSocketUNIXConnect: Can't connect: errno = 2 giving up. xinit: No such file or directory (errno 2): unable to connect to X server xinit: No such process (errno 3): Server error. seems that you have built XFree with PAM support. Just rebuild without PAM -- it's broken. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: GNU grep 2.4d
hi, there! On Mon, 31 Jan 2000, Jeremy Lea wrote: It was a local FreeBSD feature; now it is part of the official GNU grep. Any chance of -R coming back too? it is already there (-r) /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: GNU grep 2.4d
hi, there! On Tue, 1 Feb 2000, Alexander Langer wrote: It was a local FreeBSD feature; now it is part of the official GNU grep. Any chance of -R coming back too? it is already there (-r) Hmm. Somehow I dislike name-changes of params. :-( GREP guys decided to use -r (which was absent in grep 2.0). -a changed its behavior to opposite also. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATING
hi, there! On Tue, 1 Feb 2000, Sheldon Hearn wrote: Just one problem, when I follow the instructions, in usr.bin/xinstall, make depend all install clean ... Then make installworld with my configuration dies in install -c -o root -g wheel -m 444 install.1.gz /usr/share/man/man1 install: install.1.gz: No such file or directory You're not following the instructions. :-) The instructions say you must "make depend all install clean before make world or buildworld" -- you're doing it _after_ buildworld. actually instructions are wrong. you can't build xinstall before `make buildworld' now with old libc. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATING
hi, there! On Tue, 1 Feb 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Max Khon writes: : actually xinstall cannot be built before make world or make buildworld : because of undefined symbols `setflags'. What's the right thing then? make buildworld; cd /usr/src/usr.bin/xinstall; make depend all install and then, make installworld /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
UPDATING
hi, there!
--- cut here ---
2129:
{set,get}flags have been added to the tree for rather dubious
reasons. An unintended side effect of this is that you must
rebuild install before the rest of the world.
cd src/usr.bin/xinstall
make depend all install clean
before make world or buildworld. This issue may be resolved
before 4.0 goes out.
--- cut here ---
actually xinstall cannot be built before make world or make buildworld
because of undefined symbols `setflags'.
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: grep --binary-files=without-match (fwd)
hi, there! can we merge this when it's ready before freeze? -- Forwarded message -- Date: Tue, 25 Jan 100 22:47:26 -0500 (EST) From: Alain Magloire [EMAIL PROTECTED] To: Paul Eggert [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: grep --binary-files=without-match Bonjour Date: Tue, 25 Jan 2000 10:18:30 +0600 (NS) From: Max Khon [EMAIL PROTECTED] Sometimes I need to find all files that contain something. Sometimes I need only text files (e.g: vi `grep -rl xxx .` -- no binary files are desired). Thanks; that explains why you need a short-option equivalent to --binary-files=without-match. Here is a proposed patch to implement this, plus it fixes a couple of minor manual bugs I found while documenting this. It assumes all the previous patches that I've sent to the grep maintainer. 2000-01-25 Paul Eggert [EMAIL PROTECTED] * NEWS, doc/grep.1, doc/grep.texi: Add -I option. * src/grep.c (short_options, usage, main): Likewise. * doc/grep.texi: Fix some incorrect references to ASCII. Patch applied. Ruslan, there will be a beta on alpha, this weekend, grep-2.4d, I will notify you since FreeBSD'ers are the one pushing hard for the --binary-files options. -- alain To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rtld-elf, java + tya
hi, there! On Sun, 23 Jan 2000, John Polstra wrote: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 If any of you can reproduce this problem fairly reliably, please try the appended patch for "src/libexec/rtld-elf/lockdflt.c" and let me know if it solves the problem. Seems that this patch fixed the problem for me. I can not reproduce it anymore. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
collect2 and cplus-dem.c in binutils
hi, there! will collect2 be built in base system? btw binutils have in their libiberty cplus-dem.c which is incompatible with that which is used in gcc 2.9x.x. the result is broken -frepo in egcs and gcc-devel ports in -current. I filed one PR about it but I was rather tired yesterday and did not noticed that C++ demangler in gcc is more recent than that one in binutils. Affected tools are addr2line, nm, objdump and (most important) ld. The problem can be fixed by using demangle.h and cplus-dem.c from gcc when building libiberty for binutils. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rtld-elf, java + tya
hi, there! applet_viewer bombs out with a lot of stuff in the output like this (until killed -9): ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 lark:~/bin$ latest jdk-1.1.8 port, tya 1.4, -current built from sources from 19 Jan /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rtld-elf, java + tya
hi, there! On Fri, 21 Jan 2000, John Polstra wrote: Really?! Augh. Naturally this comes just hours after I have merged the latest changes into -stable *sigh*. Could you please make sure your src/libexec/rtld-elf is up-to-date? rtld.c should be at revision 1.41. yes. my src/libexec/rtld-elf/rtld.c is 1.41 Then if you can give me a stack backtrace it would help a lot. I'll try to get backtrace on Monday (when I'll get to the office) /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: grep 2.4a is now in the tree
hi, there! On Tue, 18 Jan 2000, Ruslan Ermilov wrote: The equivalent to the old -a option is --binary-files=without-match. If you want this by default, you can hardcode it in GREP_OPTIONS environment variable. I think there should be one-letter shorthand for this. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
hi, there! On Thu, 16 Dec 1999, Dave J. Boers wrote: Could you tell met the exact time on which these messages occurred? Anywhere near 10:15 or 9:15 ? nope. the time is unpredictable. sometimes it can work more than a day without spilling out those messages /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
grep -a (-stable)
hi, there! it is not possible to make short equivalent for old grep -a option (as in grep 2.3 -a is used for other purposes). it is possible to make a long option (--skip-binary) but long options are quite unusable. GREP_OPTIONS cannot help much (I want an equiv. for old 'grep -aRl pattern .') any thoughts? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: grep -a (-stable)
hi, there! On Tue, 7 Dec 1999, Sheldon Hearn wrote: it is not possible to make short equivalent for old grep -a option (as in grep 2.3 -a is used for other purposes). Que? I've used grep -a since the update to grep 2.3 and haven't noticed any strange behaviour from the -a option. You wanna explain what's going on? -stable grep (2.0 + FreeBSD-specific features) uses -a to skip binary files at all. Very useful in such context as: vi `grep -aRl foo .` in -current both 'grep -al' and 'grep -l' print names of binary files and there is no way to tell grep to skip them /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver as the default
hi, there! On Tue, 7 Dec 1999, Alex wrote: The other one is my laptop, and that one seems to be a lot faster and the system load is down (PIIX4 chipset). Except that it always gives me a timeout at boot. acd0: UJDA110/1.06 CDROM drive at ata1 as master acd0: read 2416KB/s (2416KB/s), 128KB buffer, PIO acd0: supported read types: CD-DA acd0: Audio: play, 16 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked pccard: card inserted, slot 0 ata_command: timeout waiting for interrupt Same here (similar hardware): acd0: UJDA150/1.02 CDROM drive at ata1 as master acd0: read 4134KB/s (4134KB/s), 128KB buffer, PIO acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm photo disc loaded, unlocked ata_command: timeout waiting for interrupt The command it's failing on is 0xa1 (ATA_C_ATAPI_IDENTIFY). Perhaps the driver should keep a list of misbehaving devices and not try to identify them? Same here (kernel world built from sources cvsupped 29 Nov 1999): acd0: FX320M/m02 CDROM drive at ata1 as master acd0: read 5512KB/s (5512KB/s), 256KB buffer, PIO acd0: supported read types: CD-R, CD-RW, CD-DA, packet acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked ata_command: timeout waiting for interrupt /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: grep -a (-stable)
hi, there! On Tue, 7 Dec 1999, James Howard wrote: I know about this beast. It would be nice if our out-of-box grep had this option. Hah, it used to. -stable grep used -a to skip binary files. -current does not. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
