Re: clang mangling some static struct names?

[Roman Divacky]

Yes, it does that. iirc so that you can have things like

void foo(int cond) {
  if (cond) {
static int i = 7;
  } else {
static int i = 8;
  }
}

working correctly.

I dont know why scsi_low_statics is there multiple times.

On Fri, Nov 16, 2012 at 12:36:13PM -0800, Navdeep Parhar wrote:
> On a very recent clang-built HEAD, I see that some static structures
> have a ".n" appended to their name.   For example, this declaration in
> the cxgbe driver now results in a t4_list.0 symbol in the KLD:
> 
> static SLIST_HEAD(, adapter) t4_list;
> 
> # nm if_cxgbe.ko | grep t4_list
> 0020 b t4_list.0
> 
> gcc used to leave it as t4_list.  One problem is that kgdb can't display
> such an item (it interprets the dot as a delimiter between a structure
> and its element).  Some of the structures listed at the end look strange
> for other reasons too -- for example, why should there be multiple
> scsi_low_statics.n symbols when there's only one such structure in
> scsi_low.c?
> 
> Regards,
> Navdeep
> 
> 
> full list of affected structures (and some false positives?):
> # nm kernel *.ko | grep '\.[0-9]$'
> 814802d0 b accept_filtlsthd.0
> 8125ca88 b acpi_intr_list.0
> 81292278 b cdevsw_gt_post_list.0
> 812defc8 b clock_adj.0
> 812defd0 b clock_adj.1
> 814d7ac0 b enumerators.0
> 81292460 b eventtimers.0
> 81279680 b feedertab.0
> 81248470 d intr_cpus.0.0
> 814a0378 b keyboard_drivers.0
> 81481c60 b lltables.0
> 814a17a8 b profperiod.1
> 81482280 b route_cb.0
> 81482284 b route_cb.1
> 81482288 b route_cb.2
> 8148228c b route_cb.3
> 812796d0 b sndstat_devlist.0
> 814a17a0 b statperiod.1
> 812925a4 b tstate.0
> 812925a8 b tstate.1
> 8128ab30 b twe_check_bits.lastwarn.0
> 8128ab38 b twe_check_bits.lastwarn.1
> 814804d8 b unp_defers.0
> 81488760 b vm_phys_lookup_lists.0
> 813e7900 b w_hash.0
> 813e80dc b w_hash.2
> 813e58f0 b w_lohash.0
> 813e78dc b w_lohash.2
> 0318 d proto_reg.0
> 031c d proto_reg.1
> 00c0 b fasttrap_procs.0
> 00c8 b fasttrap_procs.1
> 00d0 b fasttrap_procs.2
> 0080 b fasttrap_provs.0
> 0088 b fasttrap_provs.1
> 0090 b fasttrap_provs.2
> 0028 b t3_list.0
> 0050 b t3_uld_list.0
> 0020 b t4_list.0
> 0048 b t4_uld_list.0
>  b efdev.0
> 0190 b Counter.0
> 0194 b Counter.1
> 0198 b Counter.2
> 019c b Counter.3
> 0028 b taphead.0
> 1190 b svc_rpc_gss_callbacks.0
> 1198 b svc_rpc_gss_svc_names.0
> 0038 b scsi_low_statics.0
> 003c b scsi_low_statics.1
> 0040 b scsi_low_statics.2
> 0044 b scsi_low_statics.3
> 0048 b scsi_low_statics.4
> 0008 b feedertab.0
> 0098 b sndstat_devlist.0
> 0008 b pcx_info.0
> 000c b pcx_info.1
> 0010 b pcx_info.2
> 0014 b pcx_info.3
> 0018 b pcx_info.4
> 001c b pcx_info.5
> 0020 b pcx_info.6
> 0028 b pcx_info.7
>  b twe_check_bits.lastwarn.0
> 0008 b twe_check_bits.lastwarn.1
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [PATCH] FreeBSD compiler extensions

[Roman Divacky]

Why do you need this? Format-extensions are kernel only (which you dont use I
presume) and no-align-long-strings is boot only (which you dont use either).

Hm? :)

roman

On Tue, Jul 05, 2011 at 10:27:51AM +0200, Robert Millan wrote:
> This patch conditionalizes a pair of FreeBSD compiler extensions so
> that its CFLAGS are only used on FreeBSD.
> 
> -- 
> Robert Millan

> Index: sys/conf/kern.mk
> ===
> --- sys/conf/kern.mk  (revision 223736)
> +++ sys/conf/kern.mk  (working copy)
> @@ -1,11 +1,21 @@
>  # $FreeBSD$
>  
> +.if !defined(OPSYS)
> +OPSYS!=  uname -s
> +.endif
> +
>  #
>  # Warning flags for compiling the kernel and components of the kernel:
>  #
> +.if ${OPSYS} == "FreeBSD"
> +# FreeBSD extension, not available in upstream GCC
> +format_extensions=   -fformat-extensions
> +no_align_long_strings=   -mno-align-long-strings
> +.endif
> +
>  CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
>   -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \
> - -Wundef -Wno-pointer-sign -fformat-extensions \
> + -Wundef -Wno-pointer-sign ${format_extensions} \
>   -Wmissing-include-dirs -fdiagnostics-show-option
>  #
>  # The following flags are next up for working on:
> @@ -32,7 +42,7 @@
>  #
>  .if ${MACHINE_CPUARCH} == "i386"
>  .if ${CC:T:Mclang} != "clang"
> -CFLAGS+= -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse
> +CFLAGS+= ${no_align_long_strings} -mpreferred-stack-boundary=2 -mno-sse
>  .else
>  CFLAGS+= -mno-aes -mno-avx
>  .endif

> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: dwarf2 reader

[Roman Divacky]

There's our very own

http://sourceforge.net/apps/trac/elftoolchain/wiki/libdwarf


On Mon, Jun 13, 2011 at 10:05:15AM -0400, Ewart Tempest wrote:
> I have developed some flight recording capability in the JUNOS FreeBSD 
> based kernel, with the flight recorded data being captured in binary 
> form for performance. All the subsequent formatting and display of this 
> data is performed by a user-space application. I would like to reduce 
> the amount of time that designers spend writing formatters to display 
> their flight recorded data. kgdb is perfectly capable of displaying all 
> kernel resident data structures, and  the manner in which it does so is 
> perfectly acceptable for flight recording purposes. The code that kgdb 
> uses to support this framework is difficult to break out - does anyone 
> know of a dwarf2 reader s/w implementation that is more re-usable?
> 
> Ewart
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: make question

[Roman Divacky]

On Thu, Apr 28, 2011 at 08:50:27PM +0200, Hartmut Brandt wrote:
> On Thu, 28 Apr 2011, Roman Divacky wrote:
> 
> RD>On Thu, Apr 28, 2011 at 05:52:58PM +0200, Hartmut Brandt wrote:
> RD>> Hi Roman,
> RD>> 
> RD>> On Wed, 27 Apr 2011, Roman Divacky wrote:
> RD>> 
> RD>> RD>You seem to have messed with bsd make so I have a question for you  :)
> RD>> 
> RD>> Yeah, that was some time ago ...
> RD>> 
> RD>> RD>When a job is about to be executed in JobStart() a pipe is created 
> with
> RD>> RD>its ends connected to job->inPipe/job->outPipe. When the job is 
> actually
> RD>> RD>created in JobExec() the ps.out is set to job->outPipe so that in
> RD>> RD>JobDoOutput() we can read from that pipe and basically just parse the 
> output
> RD>> RD>for shell->noPrint and leaving it out from the output. This is meant 
> (I think)
> RD>> RD>for supressing the "filter" thing. Ie. that if we do some @command the
> RD>> RD>restoration of setting of quiet mode is filtered out.
> RD>> RD>
> RD>> RD>
> RD>> RD>In -B mode we do it differently, as we invoke one shell per command 
> we don't
> RD>> RD>have to insert quiet/verbose commands and thus avoid all the 
> piping/parsing
> RD>> RD>dance.
> RD>> RD>
> RD>> RD>So my question is - why don't we invoke one shell per command by 
> default
> RD>> RD>and avoid the piping/parsing? Is this because of performance? I think 
> that
> RD>> RD>the piping/parsing of the output can have worse impact than invoking 
> a shell
> RD>> RD>for every command. Especially given that most targets consists of 
> just one
> RD>> RD>command.
> RD>> 
> RD>> The answer is in /usr/share/doc/psd/12.make. This is so one can write 
> RD>> something like
> RD>> 
> RD>> debug:
> RD>>  DEBUG_FLAGS=-g  
> RD>>  for i in $(SUBDIR); do
> RD>>  $(MAKE) -C $$i all
> RD>>  done
> RD>> 
> RD>> instead of:
> RD>> 
> RD>> debug:
> RD>>  DEBUG_FLAGS=-g \
> RD>>  for i in $(SUBDIR); do \
> RD>>  $(MAKE) -C $$i all ; \
> RD>>  done
> RD>> 
> RD>> -B means 'backward compatible' and does what the original v7 make did: 
> one 
> RD>> shell per command. This means you don't have to write the backslashes 
> and 
> RD>> the shell variable will be seen in the sub-makes and programs.
> RD>> 
> RD>> I think we can change this, because it would break makefiles that assume 
> RD>> that the entire script is given to the shell in one piece.
> RD>
> RD>I think you answered the question why we parse the target. But I asked why
> RD>we parse the output from it.
> 
> My intention was to say why we use one shell for all commands for a given 
> rule. If we'd use one shell per line the above would not work, because the 
> first shell would see just the environment variable assignment (which 
> would be completly useless). The next shell would see a partial 'for' 
> statement and complain, and would not have the environment variable and so 
> on. So this is not so much about parsing, but about execution.
> 
> I suppose that the tricky point is with @-lines in the middle of a 
> multi-line script.
 
Unless I am reading the code wrong the "one shell per command" is the default
mode.

see in main.c:

/*
 * Be compatible if user did not specify -j and did not explicitly
 * turned compatibility on
 */
if (!compatMake && !forceJobs)
compatMake = TRUE;

You have to specify -j to turn off the compat mode.

> RD>Anyway, so you think it would be ok to change it to one shell per command 
> and
> RD>avoid the shell output parsing or not?
> 
> Unless I misunderstand the question I would say no, because this would 
> certainly render makefiles invalid that rely on the multi-line scripts 
> beeing handled by a single shell.
 
I think the chances of this breakage are pretty low as this is the default mode.

> RD>I am interested in this so that "make -j*" lets the command know that the 
> RD>output is a TTY, eg. clang can emit coloured warnings.
> 
> Hmm. I see. Just a wild guess: couldn't we use a pty to talk to the shell? 
> If that could work the question is of course what one would expect from 
> something like: make 2>&1 >make.out

I looked at what gnu make does and I think they do pretty much the same what
I suggested. Ie. one shell per command with no parsing of output by printing
directly to stdout. Thus they have no problem with the process detecting stdout
being a tty.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: make question

[Roman Divacky]

On Thu, Apr 28, 2011 at 05:52:58PM +0200, Hartmut Brandt wrote:
> Hi Roman,
> 
> On Wed, 27 Apr 2011, Roman Divacky wrote:
> 
> RD>You seem to have messed with bsd make so I have a question for you  :)
> 
> Yeah, that was some time ago ...
> 
> RD>When a job is about to be executed in JobStart() a pipe is created with
> RD>its ends connected to job->inPipe/job->outPipe. When the job is actually
> RD>created in JobExec() the ps.out is set to job->outPipe so that in
> RD>JobDoOutput() we can read from that pipe and basically just parse the 
> output
> RD>for shell->noPrint and leaving it out from the output. This is meant (I 
> think)
> RD>for supressing the "filter" thing. Ie. that if we do some @command the
> RD>restoration of setting of quiet mode is filtered out.
> RD>
> RD>
> RD>In -B mode we do it differently, as we invoke one shell per command we 
> don't
> RD>have to insert quiet/verbose commands and thus avoid all the piping/parsing
> RD>dance.
> RD>
> RD>So my question is - why don't we invoke one shell per command by default
> RD>and avoid the piping/parsing? Is this because of performance? I think that
> RD>the piping/parsing of the output can have worse impact than invoking a 
> shell
> RD>for every command. Especially given that most targets consists of just one
> RD>command.
> 
> The answer is in /usr/share/doc/psd/12.make. This is so one can write 
> something like
> 
> debug:
>   DEBUG_FLAGS=-g  
>   for i in $(SUBDIR); do
>   $(MAKE) -C $$i all
>   done
> 
> instead of:
> 
> debug:
>   DEBUG_FLAGS=-g \
>   for i in $(SUBDIR); do \
>   $(MAKE) -C $$i all ; \
>   done
> 
> -B means 'backward compatible' and does what the original v7 make did: one 
> shell per command. This means you don't have to write the backslashes and 
> the shell variable will be seen in the sub-makes and programs.
> 
> I think we can change this, because it would break makefiles that assume 
> that the entire script is given to the shell in one piece.

I think you answered the question why we parse the target. But I asked why
we parse the output from it.

Anyway, so you think it would be ok to change it to one shell per command and
avoid the shell output parsing or not?

I am interested in this so that "make -j*" lets the command know that the 
output is a TTY, eg. clang can emit coloured warnings.

Thank you, roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

make question

[Roman Divacky]

hi harti!


You seem to have messed with bsd make so I have a question for you  :)

When a job is about to be executed in JobStart() a pipe is created with
its ends connected to job->inPipe/job->outPipe. When the job is actually
created in JobExec() the ps.out is set to job->outPipe so that in
JobDoOutput() we can read from that pipe and basically just parse the output
for shell->noPrint and leaving it out from the output. This is meant (I think)
for supressing the "filter" thing. Ie. that if we do some @command the
restoration of setting of quiet mode is filtered out.


In -B mode we do it differently, as we invoke one shell per command we don't
have to insert quiet/verbose commands and thus avoid all the piping/parsing
dance.

So my question is - why don't we invoke one shell per command by default
and avoid the piping/parsing? Is this because of performance? I think that
the piping/parsing of the output can have worse impact than invoking a shell
for every command. Especially given that most targets consists of just one
command.

Thank you for the answer!

Roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD ABI?

[Roman Divacky]

On Mon, Feb 21, 2011 at 10:36:39AM -0800, Yuri wrote:
> Where is it documented?
> Are there differences with the linux ABI?
> 
> Particularly I am interested in stack alignment requirement. For example 
> i386 Solaris, Linux and MacOS have 16 bit stack alignment for procedure 
> calls. This is reflected in LLVM sources:
> 
>   if (isTargetDarwin() || isTargetLinux() || isTargetSolaris() || Is64Bit)
> stackAlignment = 16;
> 
> 
> But FreeBSD is excluded there. Is this a bug in LLVM which magically 
> doesn't cause crashes or this is correct and FreeBSD doesn't have 16 bit 
> alignment?

the alignment is specified in bytes but yes, I wonder too, what is the
stack alignment on freebsd on amd64/i386? 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: empty function macros

[Roman Divacky]

On Tue, Feb 01, 2011 at 11:25:01AM +, Alexander Best wrote:
> On Tue Feb  1 11, Roman Divacky wrote:
> > On Mon, Jan 31, 2011 at 09:51:58AM +, Alexander Best wrote:
> > > On Mon Jan 31 11, Roman Divacky wrote:
> > > > no problem with this with clang :)
> > > 
> > > hmso compiling the following code
> > > 
> > > int
> > > main(int argc, char **argv)
> > > {
> > > if (1<2)
> > > ;
> > > }
> > > 
> > > with clang -Werror code.c -o code works for you?
> > 
> > if (1<2)
> >  ;
> > 
> > gives a warning (and it should), on the other hand
> > 
> > #define NOTHING
> > 
> > if (1<2)
> >  NOTHING;
> > 
> > does not warn, which is what you want right?
> 
> actually
> 
> #define NOTHING
> 
> int
> main(int argc, char **argv)
> {
> if (1<2)
> NOTHING;
> 
> return (0);
> }
> 
> *does* warn for me:
> 
> otaku% clang test.c -o test  
> test.c:7:12: warning: if statement has empty body [-Wempty-body]
> NOTHING;
>^
> 1 warning generated.

are you using clang2.8? if so this is 2.9 feature then :)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: empty function macros

[Roman Divacky]

On Mon, Jan 31, 2011 at 09:51:58AM +, Alexander Best wrote:
> On Mon Jan 31 11, Roman Divacky wrote:
> > no problem with this with clang :)
> 
> hmso compiling the following code
> 
> int
> main(int argc, char **argv)
> {
> if (1<2)
> ;
> }
> 
> with clang -Werror code.c -o code works for you?

if (1<2)
 ;

gives a warning (and it should), on the other hand

#define NOTHING

if (1<2)
 NOTHING;

does not warn, which is what you want right?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: empty function macros

[Roman Divacky]

no problem with this with clang :)

On Sun, Jan 30, 2011 at 05:29:41PM +, Alexander Best wrote:
> hi there,
> 
> i noticed freebsd has a few of the following macros:
> 
> #define FUNC(sb)
> 
> when you do something like
> 
> if (cond)
> FUNC(i)
> 
> the compiler complains about an if statement with an empty body. any sensible
> way of dealing with this issue?
> 
> i saw some reiserfs code which does the following to silence compilers:
> 
> #define FUNC(sb) do { } while (0)
> 
> cheers.
> alex
> 
> -- 
> a13x
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: NVIDIA (port) driver fails to create /dev/nvidactl; 8.2Prerelease

[Roman Divacky]

does "kldstat | grep nvidia" show anything? if not

kldload nvidia

or

echo nvidia_load=\"YES\" >> /boot/loader.conf
reboot

does this change anything? you seem to be missing /dev/nvidiactl
which probably means that the nvidia module is not loaded

On Fri, Jan 28, 2011 at 12:43:12PM -0800, Duane H. Hesser wrote:
> I am attempting to replace the 'nv' X11 driver with the "official"
> nvidia driver from ithe x11/nvidia-driver port, in order to handle
> the AVCHD video files from my Canon HF S20.
> 
> I have been trying for several days now, having read the nvidia
> README file in /usr/local/share and everything Google has to offer.
> 
> Unfortunately devilfs is smarter and meaner than I.
> 
> The 'xorg.conf' file is created by nividia-xconfig.  The console
> output when calling 'startx' to begin the frustration is
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> X.Org X Server 1.7.5
> Release Date: 2010-02-16
> X Protocol Version 11, Revision 0
> Build Operating System: FreeBSD 8.1-RELEASE i386 
> Current Operating System: FreeBSD belinda.androcles.org 8.2-PRERELEASE 
> FreeBSD 8.2-PRERELEASE #3: Thu Jan 27 13:45:06 PST 2011 
> r...@belinda.androcles.org:/usr/obj/usr/src/sys/BELINDA i386
> Build Date: 08 January 2011  05:52:50PM
>  
> Current version of pixman: 0.18.4
> Before reporting problems, check http://wiki.x.org
> to make sure that you have the latest version.
> Markers: (--) probed, (**) from config file, (==) default setting,
> (++) from command line, (!!) notice, (II) informational,
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> (==) Log file: "/var/log/Xorg.0.log", Time: Fri Jan 28 11:32:46 2011
> (==) Using config file: "/etc/X11/xorg.conf"
> NVIDIA: could not open the device file /dev/nvidiactl (No such file or 
> directory).
> (EE) Jan 28 11:32:46 NVIDIA(0): Failed to initialize the NVIDIA kernel 
> module. Please see the
> (EE) Jan 28 11:32:46 NVIDIA(0): system's kernel log for additional error 
> messages and
> (EE) Jan 28 11:32:46 NVIDIA(0): consult the NVIDIA README for details.
> (EE) NVIDIA(0):  *** Aborting ***
> (EE) Screen(s) found, but none have a usable configuration.
> 
> Fatal server error:
> no screens found
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> There must be others out there who have been using this driver under 8.x,
> which suggests that I must be uttering the wrong incantation (or that
> devilfs is smarter and meaner than I).
> 
> I have uploaded all relevant files to my ISP's website
> 
>   http://accima.com/members/dhesser/fbsd8.2P-nvidia-driver/
> 
> so that anyone willing to make suggestions may access the information.
> 
> My primary question at this point is "Is this driver known to work under
> 8.2 PRERELEASE?"
> 
> The files on the website represent the most recent attempt, after a
> "make update" at noon (PST8PDT) yesterday (Jan 28, 2011)  followed
> by the usual upgrade process, and a deinstall/reinstall of the nvidias
> driver port.
> 
> There is one further point of confusion.  I've compared the list of
> files which the README claims to install, and found that 3 or 4 files
> related to "libvdpau.so" are not actually installed by tne driver
> port.  These files are installed by the "multimedia/libvdpau" port.
> I have installed those files from that port, with no change in the
> behavior of the driver port.  Versions of these files are actually
> included in x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-256.53/obj,
> but are not installed by the Makefile.  I've tried those too, with
> no change.  I have currently re-installed the multimedia/libvdpau
> files.
> 
> Anyone know which is correct, or why the nvidia-driver port does
> not explain?  
> 
> Note: the "hastd" problem has been fixed in stable, but now the 
> "jme" module fails to compile.
> -- 
> Duane H. Hesser 
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Removal of libobjc

[Roman Divacky]

On Fri, Oct 15, 2010 at 08:15:52PM +0100, Rui Paulo wrote:
> Hi,
> 
> I was hoping we could remove libobjc from the base system as it's seriously 
> outdated and it's not used by anything on the base system.
> 
> If there are any objections, please speak up.

please wait until the ports are converted to use libobjc2 (already in 
progress)..

it should be a few days/weeks at most now I think

roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Examining the VM splay tree effectiveness

[Roman Divacky]

are you aware of Summer of Code 2008 project by Mayur Shardul?

quoting: http://www.freebsd.org/projects/summerofcode-2008.html

Project: VM Algorithm Improvement
Student: Mayur Shardul
Mentor: Jeff Roberson
Summary:
A new data structure, viz. radix tree, was implemented and used for management 
of the resident pages. The
objective is efficient use of memory and faster performance. The biggest 
challenge was to service insert requests
on the data structure without blocking. Because of this constraint the memory 
allocation failures were not
acceptable, to solve the problem the required memory was allocated at the boot 
time. Both the data structures were
used in parallel to check the correctness and we also benchmarked the data 
structures and found that radix trees
gave much better performance over splay trees.

Ready to enter CVS/SVN: We will investigate some more approaches to handle 
allocation failures before the new data
structure goes in CVS.


On Thu, Sep 30, 2010 at 06:37:38PM +0200, Andre Oppermann wrote:
> Just for the kick of it I decided to take a closer look at the use of
> splay trees (inherited from Mach if I read the history correctly) in
> the FreeBSD VM system suspecting an interesting journey.
> 
> The VM system has two major structures:
>  1) the VM map which is per process and manages its address space
> by tracking all regions that are allocated and their permissions.
>  2) the VM page table which is per VM map and provides the backing
> memory pages to the regions and interfaces with the pmap layer
> (virtual->physical).
> 
> Both of these are very frequently accessed through memory allocations
> from userspace and page faults from the pmap layer.  Their efficiency
> and SMP scalability is crucial for many operations beginning with fork/
> exec, going through malloc/mmap and ending with free/exit of a process.
> 
> Both the vmmap and page table make use of splay trees to manage the
> entries and to speed up lookups compared to long to traverse linked
> lists or more memory expensive hash tables.  Some structures though
> do have an additional linked list to simplify ordered traversals.
> 
> A splay tree is an interesting binary search tree with insertion,
> lookup and removal performed in O(log n) *amortized* time.  With
> the *amortized* time being the crucial difference to other binary trees.
> On every access *including* lookup it rotates the tree to make the
> just found element the new root node.  For all gory details see:
>  http://en.wikipedia.org/wiki/Splay_tree
> 
> This behavior has a few important implications:
>  1) the root node and constant rotation works like a cache with
> least recent looked up node at the top and less recently ones
> close to the top;
>  2) every lookup that doesn't match the root node, ie. a cache miss,
> causes a rotation of the tree to make the newly found node the new
> root;
>  3) during the rotate it has to re-arrange and touch possibly a large
> number of other nodes;
>  4) in worst case the tree may resemble a linked list.  A splay tree
> makes no guarantee that it is balanced.
> 
> For the kernel and the splay tree usage in the VM map and page table
> some more implications come up:
>  a) the amortization effect/cost only balance if the majority of
> lookups are root node (cache) hits, otherwise the cost of
> rebalancing destroys any advantage and quickly turns into a
> large overhead.
>  b) the overhead becomes even worse due to touching many nodes and
> causing a lot of CPU cache line dirtying.  For processes with
> shared memory or threads across CPU's this overhead becomes
> almost excessive because the CPU's stomp on each others cached
> nodes and get their own caches invalidated.  The penalty is a
> high-latency memory refetch not only for the root node lookup
> but every hop in the following rebalancing operation => thrashing.
> 
> To quantify the positive and negative effects of the splay tree I
> instrumented the code and added counters to track the behavior of
> the splay tree in the vmmap and page table.
> 
> The test case is an AMD64 kernel build to get a first overview.
> Other system usages may have different results depending on their
> fork and memory usage patters.
> 
> The results are very interesting:
> 
>  The page table shows a *very* poor root node hit rate and an excessive
>  amount of rotational node modifications representing almost the
>  worst case for splay trees.
> 
> http://chart.apis.google.com/chart?chs=700x300&chbh=a,23&chds=0,127484769&chd=t:16946915,16719791,48872230,131057,74858589,105206121&cht=bvg&chl=insert|remove|lookup|cachehit|rotates|rotatemodifies
> 
>  The vmmap shows a high root node hit rate but still a significant
>  amount of rotational node modifications.
> 
> http://chart.apis.google.com/chart?chs=700x300&chbh=a,23&chds=0,21881583&chd=t:724293,723701,20881583,19044544,3719582,4553350&cht=bvg&chl=insert|remove|lookup|ca

Re: Dynamic ticks in FreeBSD

[Roman Divacky]

On Wed, Mar 31, 2010 at 04:05:33AM -0800, Tsuyoshi Ozawa wrote:
> Thank you for replying !
> 
> The patch for FreeBSD 8.0 original source is here :
> http://gist.github.com/350230

looks good

I wonder - why don't we store the callouts in binary
tree so the searching for nearest callout is faster?

what is the average length of the callout queue?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Dynamic ticks in FreeBSD

[Roman Divacky]

On Tue, Mar 30, 2010 at 05:39:04AM -0800, Tsuyoshi Ozawa wrote:
> Hello,
> 
> I started to work dynamic ticks in FreeBSD, and now experimental
> code start to work roughly.
> The code is here : http://github.com/oza/FreeBSD-8.0-dyntick

this is great! would it be possible for you to provide a patch?


thnx! roman

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: sysctl with regex?

[Roman Divacky]

On Wed, Feb 10, 2010 at 12:24:57PM +0100, Dag-Erling Sm??rgrav wrote:
> Garrett Cooper  writes:
> > C-shell globs as some programming languages referring to it as,
> > i.e. perl (which this is a subset of the globs concept) allow for
> > expansion via `*' to be `anything'. Regexp style globs for what you're
> > looking for would be either .* (greedy) or .+ (non-greedy), with it
> > being most likely the latter case.
> 
> Uh, not quite.
> 
> Formally, a regular expression is a textual representation of a finite
> state machine that describes a context-free grammar.

I dont think so regular expressions describe regular languages which are
a strict subset of context free languages.

the practical difference is that you cannot describe for example expressions
with parenthesis with a regular expression while you can with a context free
grammar...

for more info see: http://en.wikipedia.org/wiki/Chomsky_hierarchy   
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Small libstdc++ change required

[Roman Divacky]

On Sat, Dec 19, 2009 at 09:28:55AM +0200, Vlad Galu wrote:
> Hi,
> 
> as per http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36612, could one
> please apply the following patch?

the patch in question seems to be GPLv3, we cant apply it then...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Make process title - % complete

[Roman Divacky]

On Tue, Oct 20, 2009 at 02:42:17PM +0200, Ivan Voras wrote:
> Alex Kozlov wrote:
> 
> >Of course ps or top output much more convenient, but if setproctitle so
> >expencive and will be called so often, then SIGINFO may be good
> >compromise. 
> 
> Regarding speed of setproctitle(), here are some microbenchmark results 
> from the attached test source:
> 
> getpid: 3661124.75 iterations/s
> setproctitle: 591357.56 iterations/s
> 
> Meaning, setprocitle() is around 6 times more expensive than getpid(), 
> meaning it can only be pulled off nearly 600,000 calls/s on a 2.3 GHz 
> Core 2 CPU.

what about contention? setproctitle() is an sysctl so it will prevent
other sysctl's from working when being executed..
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: llvm/clang a tool chain or just a compiler for FreeBSD?

[Roman Divacky]

On Wed, Jul 22, 2009 at 06:20:36PM +0200, Ed Schouten wrote:
> * Dag-Erling Sm?rgrav  wrote:
> > "Shaowei Wang (wsw)"  writes:
> > > So what's the direction? Are we going to cut off all the GNU compiler
> > > tool chains and use the llvm/clang when it's mature.
> > 
> > Who's "we"?
> > 
> > Anyway, LLVM *isn't* mature, and it probably won't be for years, if
> > ever, so there's no point in asking.
> 
> Even though "if ever" sounds a little bit pessimistic, I agree.
> 
> Unfortunately I'm busy working on other things the last couple of
> weeks/months, but the biggest problem with LLVM/Clang right now is that
> the latest release on the website is practically useless to us.  I've
> been tracking SVN, but each time I decide to upgrade sources, I get yet
> another regression, which means I have to file bug reports. I think I
> already filed 50-60 bug reports.
> 
> For some reason there has been a lot of talking, but no hacking. It
> takes a lot of work to maintain ClangBSD, at least more than I'm willing
> to spend on it right now.

I know you disagree with me but from my pov clangbsd is mostly finished.
the integration is "just fine". what we need to do now is to get clang/llvm
and freebsd sources into shapes so there are no problems compiling freebsd
with clang.


most of the problems is with clang but there are things to improve in freebsd
too. I am working (and others as well) on both.

roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: llvm/clang a tool chain or just a compiler for FreeBSD?

[Roman Divacky]

On Wed, Jul 22, 2009 at 04:52:58PM +0100, Igor Mozolevsky wrote:
> 2009/7/22 Kostik Belousov :
> 
> > I believe that the nearest action that is quite reasonable and
> > profitable by its own merit is divorcing base compiler and compiler used
> > to build ports. Even if this means that we would "only" have different
> > versions of gcc.
> 
> 
> On a similar note, has anyone one tried clang + yasm?

I did.. it does not work and there is no future in this.
clang/llvm is getting native elf writer/assembler really soon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: llvm/clang a tool chain or just a compiler for FreeBSD?

[Roman Divacky]

On Wed, Jul 22, 2009 at 09:18:46AM +0800, Shaowei Wang (wsw) wrote:
> On Tue, Jul 21, 2009 at 9:17 PM, Roman Divacky  wrote:
> 
> > On Tue, Jul 21, 2009 at 12:34:29PM +0800, Shaowei Wang (wsw) wrote:
> > > Hi, hackers!
> > >
> > > Recently I am playing the clangbsd i386 branch and it works. I've noticed
> > > that clang using gcc to linking object code or even doing assembling.
> > >
> > > clang from FreeBSD perspective will be a whole compiler tool chain or
> > just
> > > another C/C++ compiler (may using system's [GNU]as and [GNU]ld) ?
> >
> > llvm people are working on "mc" which is a native assembler/dissasembler.
> > so the only part of the toolchain missing will be linker... now we
> > need as/ld (and gnu driver that knows how to talk to them)
> 
> 
> So what's the direction? Are we going to cut off all the GNU compiler tool
> chains and use the llvm/clang when it's mature.

there is no official stand on this but I guess the framework to enable optional
usage of clang as "cc" instead of gcc might be committed "soon"...

but that does not switch anything. there's quite a lot of work still to do
(on both fbsd and clang/llvm side). things have stalled a little recently
- it's summer, people got distracted, code freeze etc. but at least I am going
to push some more work on this after the freeze/summer...

this is my personal view not representing anything official in FreeBSD

roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: llvm/clang a tool chain or just a compiler for FreeBSD?

[Roman Divacky]

On Tue, Jul 21, 2009 at 12:34:29PM +0800, Shaowei Wang (wsw) wrote:
> Hi, hackers!
> 
> Recently I am playing the clangbsd i386 branch and it works. I've noticed
> that clang using gcc to linking object code or even doing assembling.
> 
> clang from FreeBSD perspective will be a whole compiler tool chain or just
> another C/C++ compiler (may using system's [GNU]as and [GNU]ld) ?

llvm people are working on "mc" which is a native assembler/dissasembler.
so the only part of the toolchain missing will be linker... now we
need as/ld (and gnu driver that knows how to talk to them)

roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Clang: now available from a SVN server near you!

[Roman Divacky]

On Fri, Jun 05, 2009 at 09:45:44AM +0200, Erik Cederstrand wrote:
> Hi Roman
> 
> Den 04/06/2009 kl. 14.38 skrev Roman Divacky:
> >
> >you could use llvm-ld (see the wiki for instructions how to do it).  
> >there's also some
> >effort to make gnu ld usable with llvm LTO and I guess the patch  
> >could be backported
> >to our ld. I guess
> 
> As I understand the reply from Eli Friedman[1] this is not possible  
> without at least some hacking.
> 
> The LTO work in GNU ld[2] is under GPLv3[3], as is gold[4], which  
> makes backporting patches a sticky issue.

we can ask the person who did the gnu ld work to relicense the one patch
under gplv2
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Clang: now available from a SVN server near you!

[Roman Divacky]

On Thu, Jun 04, 2009 at 02:35:56PM +0200, Erik Cederstrand wrote:
> Den 04/06/2009 kl. 11.38 skrev Ed Schouten:
> 
> >You can now build your very own version of FreeBSD with Clang  
> >installed
> >as /usr/bin/cc as follows:
> 
> Thanks for your hard work, Ed. This is great news!
> 
> You might want to mention that a few parts are still GCC-compiled due  
> to bugs in Clang ( see http://wiki.freebsd.org/ 
> BuildingFreeBSDWithClang). Also, it's very encouraging that the ports  
> run you did with Erwin 
> (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005274.html ) 
> compiles over 7000 ports with Clang.
> 
> I've asked in the Clang list, but I'd like an opinion from FreeBSD  
> folks, too: Clang supports LTO 
> (http://llvm.org/docs/LinkTimeOptimization.html ), which has a potential 
> for performance improvements. It doesn't work  on FreeBSD because the 
> linker we have (in binutils) doesn't know about  the libLTO that LLVM 
> provides. There's a new linker from GNU called  Gold, but as far as I know 
> it's GPLv3 licensed and therefore  undesirable at least to have in base. 
> LLVM provides a linker (http://llvm.org/cmds/llvm-ld.html ) but "it doesn't 
> interact correctly with conventional nm/ar/etc" 
> (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005296.html ). 
> There's the ELF toolchain project (elftoolchain.sourceforge.net/)  but a 
> BSD-licensed ld hasn't been developed yet.
> 
> What would be the best way to get LTO to work on FreeBSD?

you could use llvm-ld (see the wiki for instructions how to do it). there's 
also some 
effort to make gnu ld usable with llvm LTO and I guess the patch could be 
backported 
to our ld. I guess
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Clang: now available from a SVN server near you!

[Roman Divacky]

On Thu, Jun 04, 2009 at 11:38:31AM +0200, Ed Schouten wrote:
> Good news everyone!
> 
> As I mentioned at BSDCan, I was going to import my FreeBSD+Clang branch
> into SVN. Tuesday I finally had some time to do it, so here's the
> result:
> 
>   http://svn.freebsd.org/viewvc/base/projects/clangbsd/
> 
> You can now build your very own version of FreeBSD with Clang installed
> as /usr/bin/cc as follows:
> 
> - Check out the clangbsd branch from our SVN repository:
>   svn co svn://svn.freebsd.org/base/projects/clangbsd
> 
> - Put this in /etc/src.conf:
>   WITH_CLANG=
>   WITH_CLANG_IS_CC=
>   NO_WERROR=
>   WERROR=
> 
> - Just run `make buildworld' and `make installworld'.

it should be able to compile a bootable kernel on amd64/i386 as well.. so
feel free to test that too :)


pgp2Mu4IDqjGP.pgp
Description: PGP signature

Re: In search of a video card

[Roman Divacky]

On Wed, May 13, 2009 at 08:06:34PM -0700, Josef Grosch wrote:
> 
> I'm in search for a decent video card. I currently have an Nvidia GeForce
> 8400 GS. It worked pretty well i386 FreeBSD 6.2. I have upgraded my home
> machine and I am running amd64 FreeBSD 7.2 and it just refuses to go into
> X. It just hangs. I've been poking around and, based on what I read, some
> FreeBSD developers and Nvidia have gotten into a finger pointing contest as
> to what is the problem. Its all very nice but doesn't help me much.
> 
> So, can any one recommend a good video card? What I'm looking for is
> 
>   * Works with amd64 FreeBSD 7.2
>   * DVI 
>   * PCI-E x16
>   * 512 MB or more
>   * Not going to cost an arm and a leg

you can try nouveau driver in the meantime
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: C99: Suggestions for style(9)

[Roman Divacky]

I like the part about using as many variables as possible because
of documentation and performance enhancements. I tend to like
the other changes as well..


On Sun, Apr 26, 2009 at 09:02:36AM +0200, Christoph Mallon wrote:
> Hi hackers@,
> 
> as some of you may have noticed, several years ago a new millenium 
> started and a decade ago there was a new C standard. HEAD recently 
> switched to C99 as default (actually gnu99, but that's rather close). So 
> it's finally time to re-examine wether style(9) needs to be accomodated.
> The diff with the proposed changes is attached. Below are the changes 
> with some further explanations. They are in the order as they appear in 
> style(9).
> Maybe using all of these changes is a bit too big change at once, but 
> I'd like some of them applied to style(9). So, please consider the 
> proposed changes individually and not a as a all-or-nothing package.
> 
> >-Do not put declarations
> >-inside blocks unless the routine is unusually complicated.
> >+Prefer declaring loop iterators in the for-statement to limit their scope.
> > .Bd -literal
> >-for (; cnt < 15; cnt++) {
> >+for (int cnt = 0; cnt < 15; cnt++) {
> [...]
> >-When declaring variables in functions declare them sorted by size,
> >-then in alphabetical order; multiple ones per line are okay.
> >+When declaring variables in functions declare them sorted in alphabetical 
> >order;
> >+prefer one declaration per line, especially when pointer declarators or 
> >+initializations are involved.
> > If a line overflows reuse the type keyword.
> > .Pp
> >-Be careful to not obfuscate the code by initializing variables in
> >-the declarations.
> >-Use this feature only thoughtfully.
> >-DO NOT use function calls in initializers.
> >+Prefer initializing variables right at their declaration.
> >+When the value is not supposed to change in the function, make the 
> >variable
> >+const.
> >+This makes it easier for a reader to identify the where the value of a 
> >variable
> >+originates.
> >+Do not reuse the same variable in a different context, declare a new 
> >variable.
> > .Bd -literal
> >-struct foo one, *two;
> >-double three;
> >-int *four, five;
> >-char *six, seven, eight, nine, ten, eleven, twelve;
> >+struct foo *bar;
> >+struct foo baz = { 42, "qux" };
> > 
> >-four = myfunction();
> >+FILE *const f = fopen("name", "r");
> >+if (f == NULL)
> >+err("Failed to open file");
> >+/* We can safely assume that f is not changed anymore, even if the
> >+ * function is a hundred lines long */
> 
> This change is to reduce the scope of local variables. For reasons why 
> this does not cost anything in terms of stack space, please see the last 
> change, which adds explanations about local variables.
> Smaller scopes and distinct variables for distinct contexts make it 
> easier for readers of the code to identify the def-use-chains of 
> variables, because there are less places with assignments to a variable 
> and the scope is smaller. Also, when a variable is initialised right at 
> its declaration and is not supposed to change, you can emphasize this by 
> making it const.
> I looked at older discussions regarding this topic and identified 
> several concerns, which were raised. I'll address them below:
> 
> - It does not add anything to the language.
> Well, yes, just like if, do, for, goto, the comma operator, compound 
> assignment (+=, ...), ++/-- and many other things. All you need to be 
> Turing complete is lambda calculus - there hardly can be less syntax. 
> But, like all mentioned constructs, it makes the code more concise.
> 
> - It leads to sloppy code. You could reuse another variable or should 
> think again whether you really need this variable.
> Reusing variables in different contexts is error prone and bad for 
> maintainability. You could reuse a variable, which is not as dead as you 
> thought. More local variables cost nothing, especially no stack space, 
> see the last proposed changed below. It is good to use more local 
> variables, because it gives the reader a name, which carries 
> information. Also it makes it easier for a reader (and the compiler!) to 
> identify, which expressions are the same. You could repeat 
> foo->long_name->even_longer_name[2 * i + 1] five times or just declare a 
> local variable and cache the value to make it easier to read.
> It also enables the compiler to produce better warnings: If you declare 
> a new variable, it is not initialised and if you do not initialise it on 
> all paths before a use, the compiler will warn you. But if you reuse an 
> older variable, it is already initialised by its former uses and so you 
> get no warning, but operate on garbage values (the old value from the 
> previous use).
> So it does not lead to slopyy code, but better code, which is easier to 
> comprehend, the compiler can better help you to prevent bugs, and as a 
> side effect the compiler can produce better 

Re: [PATCH]: today highlighting in [n]cal

[Roman Divacky]

On Mon, Apr 20, 2009 at 06:24:11PM +0200, Alexey Shuvaev wrote:
> On Mon, Apr 20, 2009 at 04:02:19PM +0200, Roman Divacky wrote:
> > On Mon, Apr 20, 2009 at 11:21:26AM +0200, Simon 'corecode' Schubert wrote:
> > > Hey Roman,
> > > 
> > > Roman Divacky wrote:
> > > >I made this patch that highlights today in cal/ncal just like gnu
> > > >cal does..
> > > >
> > > > www.vlakno.cz/~rdivacky/cal.patch
> > > 
> > > Thanks for this patch, I've been meaning to hack one up properly, but 
> > > never got to it.  They problems I was facing seem to exist also with your 
> > > patch:
> > > 
> > > - only works for wide (cal) mode, not ncal mode
> > > - probably won't work properly with year displays:  the year printing 
> > > parts of the code use a length argument to printf ("%*s"), which will 
> > > confuse escape sequences with actual printed characters
> > 
> > after addressing Simon's concerns here's a new patch:
> > 
> > www.vlakno.cz/~rdivacky/cal2.patch
> > 
> > this disables the highlighting for year printing because it's broken
> > and introduces the highlighting to ncal as well...
> >
> Nice!
> It depends on one more lib now:
> 
> Modified:
> ~> ldd /usr/bin/ncal 
> /usr/bin/ncal:
> libcalendar.so.4 => /usr/lib/libcalendar.so.4 (0x800643000)
> libncurses.so.7 => /lib/libncurses.so.7 (0x800745000)
> libc.so.7 => /lib/libc.so.7 (0x80088f000)
> 
> Old:
> ~> ldd /home/jails/kde4/usr/bin/ncal
> /home/jails/kde4/usr/bin/ncal:
> libcalendar.so.4 => /usr/lib/libcalendar.so.4 (0x800642000)
> libc.so.7 => /lib/libc.so.7 (0x800744000)
 
yes so?

> Does it work good in single user mode?
> (Don't want to go to it right now myself).
> OTOH, who needs cal/ncal in single user mode? :)

I guess it should.. it depends strictly on terminal, didnt test it though
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [PATCH]: today highlighting in [n]cal

[Roman Divacky]

On Mon, Apr 20, 2009 at 11:21:26AM +0200, Simon 'corecode' Schubert wrote:
> Hey Roman,
> 
> Roman Divacky wrote:
> >I made this patch that highlights today in cal/ncal just like gnu
> >cal does..
> >
> > www.vlakno.cz/~rdivacky/cal.patch
> 
> Thanks for this patch, I've been meaning to hack one up properly, but 
> never got to it.  They problems I was facing seem to exist also with your 
> patch:
> 
> - only works for wide (cal) mode, not ncal mode
> - probably won't work properly with year displays:  the year printing 
> parts of the code use a length argument to printf ("%*s"), which will 
> confuse escape sequences with actual printed characters

after addressing Simon's concerns here's a new patch:

www.vlakno.cz/~rdivacky/cal2.patch

this disables the highlighting for year printing because it's broken
and introduces the highlighting to ncal as well...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [PATCH]: today highlighting in [n]cal

[Roman Divacky]

On Mon, Apr 20, 2009 at 01:53:56PM +0200, Simon 'corecode' Schubert wrote:
> Roman Divacky wrote:
> >On Mon, Apr 20, 2009 at 11:21:26AM +0200, Simon 'corecode' Schubert wrote:
> >>Hey Roman,
> >>
> >>Roman Divacky wrote:
> >>>I made this patch that highlights today in cal/ncal just like gnu
> >>>cal does..
> >>>
> >>>   www.vlakno.cz/~rdivacky/cal.patch
> >>Thanks for this patch, I've been meaning to hack one up properly, but 
> >>never got to it.  They problems I was facing seem to exist also with your 
> >>patch:
> >>
> >>- only works for wide (cal) mode, not ncal mode
> >
> >it works for ncal 
> 
> I didn't try it on FreeBSD, but from inspecting the code, you only 
> modified mkmonthb(), which is called for the cal-style layout, but not for 
> the ncal-style layout (then mkmonth() is called).
 
yes... and if I read the code correctly the very same approach should
work for the mkmonth() as well.. it should be copy'n'paste

> >>- probably won't work properly with year displays:  the year printing 
> >>parts of the code use a length argument to printf ("%*s"), which will 
> >>confuse escape sequences with actual printed characters
> >
> >I am not sure what you mean by year printing can you give me the
> >exact command line?
> 
> just try "cal 2009" or so, basically use printyear[b].

this works
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [PATCH]: today highlighting in [n]cal

[Roman Divacky]

On Mon, Apr 20, 2009 at 12:24:32PM +0200, Roman Divacky wrote:
> On Mon, Apr 20, 2009 at 11:21:26AM +0200, Simon 'corecode' Schubert wrote:
> > Hey Roman,
> > 
> > Roman Divacky wrote:
> > >I made this patch that highlights today in cal/ncal just like gnu
> > >cal does..
> > >
> > >   www.vlakno.cz/~rdivacky/cal.patch
> > 
> > Thanks for this patch, I've been meaning to hack one up properly, but 
> > never got to it.  They problems I was facing seem to exist also with your 
> > patch:
> > 
> > - only works for wide (cal) mode, not ncal mode
> 
> it works for ncal 

oh.. it doesnt... I was under the impression that it does... I'll take a look 
at it
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [PATCH]: today highlighting in [n]cal

[Roman Divacky]

On Mon, Apr 20, 2009 at 11:21:26AM +0200, Simon 'corecode' Schubert wrote:
> Hey Roman,
> 
> Roman Divacky wrote:
> >I made this patch that highlights today in cal/ncal just like gnu
> >cal does..
> >
> > www.vlakno.cz/~rdivacky/cal.patch
> 
> Thanks for this patch, I've been meaning to hack one up properly, but 
> never got to it.  They problems I was facing seem to exist also with your 
> patch:
> 
> - only works for wide (cal) mode, not ncal mode

it works for ncal 

> - probably won't work properly with year displays:  the year printing 
> parts of the code use a length argument to printf ("%*s"), which will 
> confuse escape sequences with actual printed characters

I am not sure what you mean by year printing can you give me the
exact command line?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

[PATCH]: today highlighting in [n]cal

[Roman Divacky]

hi

I made this patch that highlights today in cal/ncal just like gnu
cal does..

www.vlakno.cz/~rdivacky/cal.patch


unless objected I plan to commit this soon (with fixes to style(9))

roman


pgp6bLOqaYr81.pgp
Description: PGP signature

Re: hosted, or not (Re: Renaming all symbols in libmp(3))

[Roman Divacky]

On Sat, Feb 28, 2009 at 10:24:56AM +0100, Ed Schouten wrote:
> * per...@pluto.rain.com  wrote:
> > So perhaps one solution would be to compile libmp with -ffreestanding?
> 
> And all applications that use .

which is a nonsense... please move forward
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: hosted, or not (Re: Renaming all symbols in libmp(3))

[Roman Divacky]

On Thu, Feb 26, 2009 at 11:46:22PM -0800, per...@pluto.rain.com wrote:
> > >> By default, LLVM has a built-in prototype of pow(), similar to
> > >> GCC. Unlike GCC, LLVM raises a compiler error by default ...
> 
> > ... it's invalid code to have a function named pow()
> > in a hosted environment which is not /The/ pow().
>   ^^^
> 
> I don't suppose LLVM supports a commmand-line switch to use embedded
> mode instead of hosted?

of course it does -ffreestanding
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: TUNABLE_INT question

[Roman Divacky]

On Tue, Feb 17, 2009 at 05:51:13PM -0500, John Baldwin wrote:
> On Tuesday 17 February 2009 5:21:42 pm Roman Divacky wrote:
> > On Tue, Feb 17, 2009 at 09:31:12AM -0500, John Baldwin wrote:
> > > On Friday 13 February 2009 5:16:07 pm Roman Divacky wrote:
> > > > On Fri, Feb 13, 2009 at 03:55:44PM -0500, Ryan Stone wrote:
> > > > > __FILE__ is a string so you can't concat that with anything to 
> > > > > produce 
> an
> > > > > identifier.  In any case, the variable is static so there can't be any
> > > > > collision problems with other files.
> > > > 
> > > > I was talking about the SYSINIT parameter. thats a section in a .o
> > > > file, and I am getting collisions there...
> > > 
> > > Hmm, are you doing something like this:
> > > 
> > > #define FOO(string) \
> > >   TUNABLE_INT(string ## ".bar", &bar); \
> > >   TUNABLE_INT(string ## ".foo", &foo); \
> > > 
> > > FOO(baz)
> > > 
> > > That would collide as both of the TUNABLE_INT() invocations would have 
> > > the 
> > > same __LINE__ (the line number of the 'FOO(baz)').
> > 
> > no.. it was just two tunables in two files that happened to end  up in the 
> same
> > line. fixed now
> 
> Hmmm, odd.  Those should be static and not matter.

the symbol itself is static, but the section ELF section created might collide.

anyway, this has been fixed and is not a problem anymore for me
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: TUNABLE_INT question

[Roman Divacky]

On Tue, Feb 17, 2009 at 09:31:12AM -0500, John Baldwin wrote:
> On Friday 13 February 2009 5:16:07 pm Roman Divacky wrote:
> > On Fri, Feb 13, 2009 at 03:55:44PM -0500, Ryan Stone wrote:
> > > __FILE__ is a string so you can't concat that with anything to produce an
> > > identifier.  In any case, the variable is static so there can't be any
> > > collision problems with other files.
> > 
> > I was talking about the SYSINIT parameter. thats a section in a .o
> > file, and I am getting collisions there...
> 
> Hmm, are you doing something like this:
> 
> #define FOO(string) \
>   TUNABLE_INT(string ## ".bar", &bar); \
>   TUNABLE_INT(string ## ".foo", &foo); \
> 
> FOO(baz)
> 
> That would collide as both of the TUNABLE_INT() invocations would have the 
> same __LINE__ (the line number of the 'FOO(baz)').

no.. it was just two tunables in two files that happened to end  up in the same
line. fixed now
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: TUNABLE_INT question

[Roman Divacky]

On Fri, Feb 13, 2009 at 03:55:44PM -0500, Ryan Stone wrote:
> __FILE__ is a string so you can't concat that with anything to produce an
> identifier.  In any case, the variable is static so there can't be any
> collision problems with other files.

I was talking about the SYSINIT parameter. thats a section in a .o
file, and I am getting collisions there...


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

TUNABLE_INT question

[Roman Divacky]

hi
  
#define TUNABLE_INT(path, var)  \
static struct tunable_int __CONCAT(__tunable_int_, __LINE__) = { \
(path), \
(var),  \
};  \
SYSINIT(__CONCAT(__Tunable_init_, __LINE__),\
SI_SUB_TUNABLES, SI_ORDER_MIDDLE, tunable_int_init, \
&__CONCAT(__tunable_int_, __LINE__))
  
  
this is the code for TUNABLE_INT macro, the first param
to SYSINIT is an "uniquifier" which is "__Tunable_init_X"
where is is a number specifying line.
  
if I read it correctly there is no protection from collisions, am
I right?  is it a proper fix to concat __FILE__ there too?
  
thnx
  
roman




pgpx7LGWF2Y4G.pgp
Description: PGP signature

Re: Posting a bounty for the nVidia 64-bit wishlist

[Roman Divacky]

On Thu, Jan 01, 2009 at 02:03:13PM +0900, Alastair Hogge wrote:
> On Thursday 01 January 2009 10:57:26 Garrett Cooper wrote:
> > Hello Hackers,
> > I have a request related to making FreeBSD to be a viable platform
> > on AMD/Intel 64-bit architectures, such that functionality as
> > requested by Chris (see:
> > ). Please note that
> > some of these things would also no doubt positively affect other
> > groups (ATI, Intel, etc) when writing x*64 drivers for FreeBSD, so the
> > list isn't just necessarily just applicable to nVidia.
> > If someone could list a number of sys/... files that I could look
> > at in order to get a brief grasp of what needs to be modified to
> > support proper 64-bit architecture vmem, pmap, etc, that would be
> > extremely helpful; I want to establish a reasonable timeframe and
> > skill set required for the task set, so I can establish a reasonable
> > monetary figure and/or resources to donate to the project.
> > Also, if anyone else is interested in this pursuit (I know there
> > are quite a few), feel free to contact me so we can coordinate our
> > efforts and pool our resources to get these sets of loose ends finally
> > tied up to have a more accessible FreeBSD based desktop.
> > Thanks!
> > -Garrett
> Are you aware of the efforts the PC-BSD project is making?
> 
> http://trac.pcbsd.org/browser/freebsd-projects/nvidia-work

wow, is anyone working on this being review/integrated?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: How to access kernel memory from user space

[Roman Divacky]

On Mon, Dec 22, 2008 at 06:05:34PM -0600, Gerry Weaver wrote:
> Hello All,
> 
> I am working on a driver that collects various network statistics via pfil. I 
> have a simple array of structures that I use to store the statistics. I also 
> have a user space process that needs to collect these statistics every second 
> or so. A copy operation from kernel to user space would be too expensive. Is 
> there a mechanism that would allow me to gain direct access to my kernel 
> array from user space? The user process would only need read access. It seems 
> like maybe this could be done with mmap, but since this is not a character 
> driver, there is no device file etc.. I'm a newbie, so I apologize if this is 
> something that should be obvious.

would it be feasible to allocate a buffer in userspace and map it into the 
kernelspace?
if so, I believe sf_buf (man 9 sf_buf) should work


   roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [help]strange problem about gethostbyname/getaddrinfo

[Roman Divacky]

On Wed, Dec 10, 2008 at 02:36:27PM +0800, Cheng Renquan wrote:
> On Wed, Dec 10, 2008 at 1:57 PM, ? <[EMAIL PROTECTED]> wrote:
> > hi,all,we have a project which must resolv some domains in the server
> > process
> > our system in FreeBSD 6.2 or 6.3, the server process may open 7000+
> > sockets,not fork
> > we have set the maxopensockets as 65536,as follows:
> 
> Use strace to trace it,

I personally found strace on fbsd to lie to me everytime. I'd avoid
that and use ktrace/kdump instead...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: TCSBRK not implemented in linux compat

[Roman Divacky]

On Tue, Dec 02, 2008 at 09:56:28PM +0100, Arjan van der Velde wrote:
> Hi,
> 
> While trying to get a linux binary running on FreeBSD I encountered  
> the following problem during serial port I/O.
> 
> Dec  1 22:22:34 soekris kernel: linux: pid 7239 (linuxbinary): ioctl  
> fd=0, cmd=0x5409 ('T',9) is not implemented
> 
> 0x5409  turns out to be TCSBRK, which is not implemented (yet?). Can  
> anyone give me some clues where / how to start implementing this? It  
> seems like the linux way of handling it is to call tcdrain(), but I'm  
> not sure as to how this translates to the FreeBSD compat layer.

I believe you want to talk to Ed Schouten as this is a TTY thing..

I CCed him
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: minor change to src/usr.bin/window/wwend.c

[Roman Divacky]

On Sat, Nov 29, 2008 at 10:47:25PM -0500, Eitan Adler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Fixes two errors when building with -ansi -Wall
> 
> 
> - --- wwend.c.backup  2008-11-29 22:41:42.0 -0500
> +++ wwend.c   2008-11-29 22:46:08.0 -0500
> @@ -40,12 +40,14 @@
>"$FreeBSD: src/usr.bin/window/wwend.c,v 1.4 2001/05/17 09:38:49
> obrien Exp $";
>  #endif /* not lint */
> 
> +#include 
>  #include 
>  #include "ww.h"
>  #include "tt.h"
> 
>  /*ARGSUSED*/
> - -wwend(exit)
> +int
> +wwend(int exit)
>  {
>   if (tt.tt_checkpoint) {
>   (void) alarm(0);

please use -current, I already fixed this in -current a week or so ago...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: linux-libusb done

[Roman Divacky]

On Sun, Oct 26, 2008 at 11:49:02AM +0100, Martin Laabs wrote:
> Hi,
> 
> I've build succesfully an androgynous libusb. This is a libusb in
> linux binary format with freebsd-like usb-access. (I use it to
> run a jtag-debugging utility which is supplied as a linux
> binary only.)
> Unfortunately I had to patch the linux.ko module to support the
> ioctl calls out of the linux application.
> I can supply the libusb.so, a patch for the source of libusb 
> as well as the linux_ioctl.c on request.
> Unfotunately I did not save the original linux_ioctl.c so I can not
> publish a patch yet. (I'll do a cvsup these days ..)
> 
> Anyone who wants to maintain such a port?

great work martin!

please show us the linuxulator patch and I'll see what I can do about it...

roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: llvm/clang early test

[Roman Divacky]

On Wed, Oct 08, 2008 at 04:29:46PM +0300, Volodymyr Kostyrko wrote:
> Hi all.
> 
> Does anyone tried to build world with clang (devel/llvm-devel)? I just 
> have tested clang on some code from our tree, gzip and bzip2 for 
> example. Well... it works. Gzip compiled with clang become faster, bzip2 
> don't... Right now I'm playing with world making it compile with clang. 
> If anyone doing the same thing we can share some thoughts and patches...

check this patch: www.vlakno.cz/~rdivacky/clang.patch

I am playing with it as well :)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Building custom kernel with new files

[Roman Divacky]

On Sat, Aug 16, 2008 at 10:10:02PM +1200, Ryan French wrote:
> Hi All,
> 
> I am currently trying to build a custom kernel for my Google Summer of Code, 
> and am running into a bit of a problem. I have all of my code compiling, but 
> when I get to the linking stage as soon as it comes to the new files I have 
> installed it says the *.o does not exist. I have added the files 
> to /conf/files, and well as added the files to /conf/options and /conf/NOTES, 
> and the option is set in my Makefile for the kernel. Is there another step I 
> need to do before I can build the kernel?

how do you build the kernel? adding to conf/files and conf/options should
be sufficient...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: textvp_fullpath

[Roman Divacky]

On Thu, Aug 14, 2008 at 09:20:12PM +0300, Uladzislau Rezki wrote:
> Hello folks,
>   
> I'm using "textvp_fullpath" function to get full path from vnode up to root 
> dir.
> The problem is that, sometimes it works, sometimes no.
> 
> I know that "textvp_fullpath" goes through the cache of the vnode and
> try to build full path.
> 
> Are there any other ways to get full path?
> I haven't had any ideas yet, that is why I am asking you.

no... the vnode->full_path lookup is unreliable by definition
in FreeBSD... what exactly are you trying to acomplish? I believe
there might be other way to do whatever you want to do..


roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

kmem_alloc_wait and memory pools questions

[Roman Divacky]

hi

I have two questions:

1) is kmem_alloc_wait() expensive operation? I believe it's not
very cheap looking at the code but I want confirmation

2) is there a support for memory pools in FreeBSD?

to give you a little background why I am asking this. In NetBSD Andrew Doran
claims that replacing allocation from a memory submap with an allocation
from a memory pool for exec*() args he can speedup exec*() by ~25%

I wonder if this applies to FreeBSD too so I am investigating it a little.

thnx!

roman

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Lack of Flash support is no longer acceptable. Bounty established...

[Roman Divacky]

On Fri, Jun 20, 2008 at 08:39:06AM +0200, Alexander Leidinger wrote:
> Quoting John Kozubik <[EMAIL PROTECTED]> (from Thu, 19 Jun 2008  
> 14:38:11 -0700 (PDT)):
> 
> >First, a bounty has been posted here:
> >
> >http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html
> >
> 
> From the site:
> ---snip---
> I will pay $200 to whoever can compose a working and stable recipe for  
> running Adobe Flash 9 inside of the FreeBSD native version of Opera 9  
> on FreeBSD 6.x. This shouldn't be that hard - in fact, there is  
> already a linux-flashplugin9 port.
> ---snip---
> 
> Comments from other people with some more money not included here...
> 
> And now the sad reality check: linux-flashplugin9 will _never_ work on  
> 6.x (lack of linux 2.6 emulation, and this is not a MFC candidate).
> 
> Getting it to work on 7.x is possible. "All what you need" is  
> nspluginwrapper to get it running in the native  
> firefox/opera/whatever, and someone who is willing to debug the  
> linuxulator (on -current, as there is a more complete 2.6  
> compatibility there, and this can be MFCed to 7.x) and find the  
> bug/problem which is causing the crashes. Whoever is willing to tackle  
> this: head over to emulation@ (CCed) and ask what debugging  
> possibilities we have in the linuxulator.

I tried to debug the flash9 and failed badly. It might be that I overlooked
something trivial but...

the flash9 is a big binary-only monster and basically the only trace
of what its doing you can get is a syscall-trace. Which is not that much
useful. I didnt find any missing syscalls or something like that and the
fail is a complete mystery for me otoh I looked at this a LOONG time ago.
I might want to look at it again (after some other things settle)


anyway... I dont think that flash9 crashes are related to 2.6 emulation in any
way. iirc it runs (and crashes) on 2.4 as well. I remember it crashes in 
$the_thing_that_ff_uses_to_report_bugs which was some proprietary app which
got replaced in ff3.0, you might want to check what happened.


anyway - if someone wants to debug this, feel free to contact me, I am willing
to help

roman
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Decent 3D acceleration in 64bit mode?

[Roman Divacky]

On Thu, Jun 19, 2008 at 05:36:44PM -0400, Chuck Robey wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Mike Meyer wrote:
> > On Thu, 19 Jun 2008 14:00:42 -0400 "Zaphod Beeblebrox" <[EMAIL PROTECTED]> 
> > wrote:
> > 
> >> On Wed, Jun 18, 2008 at 8:13 AM, Stephen Hocking <[EMAIL PROTECTED]>
> >> wrote:
> >>> Given that Nvidia aren't offering a driver for their cards for 64bit
> >>> FreeBSD, is anyone else having success using another (preferably
> >>> PCI-E) card with 3D acceleration?
> >> I'd love to be told I'm wrong, but my understanding is that the issues
> >> blocking the nvidia driver would also effectively block a driver for which
> >> we had the source.
> > 
> > Is there an open source driver with good 3D acceleration?
> > 
> > 
> Could I ask, does anyone here know the reason (even in general) that the 
> Nvidia
> driver isn't working on the i386?
> 
> I mean, I was wondering what might be my next project ... I have the 
> machinery,
> and the source code is totally available, it's not a matter of Nvidia giving 
> out
> a binary-only module, right?  So, is anything more known?

you might want to port nouveau (http://nouveau.freedesktop.org/wiki/) to 
FreeBSD.

that would be a great thing to have
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD and LLVM

[Roman Divacky]

On Tue, May 20, 2008 at 07:06:39PM +0200, Ed Schouten wrote:
> Hello everyone,
> 
> First of all, for those of you who went to BSDCan, I hope you had a
> pleasant flight/trip back home. :-)
> 
> On Saturday I went to the LLVM talk (see http://llvm.org/), which I
> really enjoyed. On Friday Remko Lodder and I already talked with him
> about the LLVM project. I was excited about the project, so I decided to
> give it a try at the office.
> 
> At first I tried LLVM 2.2 with LLVM GCC4 4.2 from Ports, but it didn't
> work like expected. I won't go into many details about it.
> 
> When I discussed the problems I was seeing on my system at the office,
> someone pointed me to the beta tarballs of the upcoming version 2.3,
> which I installed by patching our FreeBSD port.
> 
>   http://llvm.org/prereleases/2.3/
> 
> As an ideal benchmark, I decided to compile an i386 kernel using the
> LLVM 2.3 snapshot. I didn't expect it to happen, but it works! I was

did you try clang as well? I wonder what it's able to do

> capable of successfully booting into single user mode and shutting it
> down safely. There is one problem however:
> 
>   http://llvm.org/bugs/show_bug.cgi?id=2267
> 
> For some reason, the inline asm support of LLVM is incomplete and causes
> compilation errors when generating some of the atomic functions in
> i386/include/atomic.h (lines 262 to 265). To work around this, I made
> the functions non-atomic. Silly, I know, but it was good enough to
> perform some basic tests.
> 
> I think it would be nice if LLVM would once become our standard C
> compiler. LLVM currently uses GCC as its frontend, which proves to be
> somewhat compatible with the original GCC>

yeah... thats a worthy goal :)

thnx!

roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: hashinit versus phashinit

[Roman Divacky]

On Tue, May 06, 2008 at 02:25:56AM -0400, David Schultz wrote:
> On Mon, May 05, 2008, Roman Divacky wrote:
> > hi
> > 
> > when we want to use a hash table in kernel we call "hashinit" which
> > initializes a hash table with power-of-2 size. There's also "phashinit"
> > that creates hash table of size that is a prime number. This was
> > added in 1995 by davidg@ but it is not used anywhere in the kernel.
> > 
> > phk@ commited rev. 1.30 of vfs_cache.c replacing phashinit with hashinit
> > stating that it's better because it replaces a division with logical and.
> > is this reason still valid today? (the commit was done almost 11 years ago)
> > 
> > is there still any reason why not use the phashinit instead of hashinit?
> > I believe using prime-sized hash table might have positive performance
> > impact...
> 
> There's a tradeoff.
> 
> The argument for using powers of 2 is that division takes many
> times longer than a logical AND.
> 
> The argument for using primes is that if your hash function isn't
> as good as you thought it was, or if the data has some regularity
> you weren't expecting, you can get screwed a lot more easily with
> a power of 2 hash table.  With a prime-sized hash table, you only
> get screwed if lots of your data is congruent modulo the prime,
> which is very rare.
> 
> Most general-purpose hash implementations I've used (e.g., GNU
> libstdc++, Sun JDK, Microsoft .NET) use prime table sizes,
> probably to make it less likely that programmers will shoot
> themselves in the foot with pathological data or bad hash functions.

yes... a division takes roughly 40 cycles on modern i386 hw, while
and is just 1, but does it matter compared to the access times of
memory these days?

the ratio between cpu-speed/mem-speed has changed a lot. I am not
arguing if it's still true that avoiding the division helps the performance
these days...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

hashinit versus phashinit

[Roman Divacky]

hi

when we want to use a hash table in kernel we call "hashinit" which
initializes a hash table with power-of-2 size. There's also "phashinit"
that creates hash table of size that is a prime number. This was
added in 1995 by davidg@ but it is not used anywhere in the kernel.

phk@ commited rev. 1.30 of vfs_cache.c replacing phashinit with hashinit
stating that it's better because it replaces a division with logical and.
is this reason still valid today? (the commit was done almost 11 years ago)

is there still any reason why not use the phashinit instead of hashinit?
I believe using prime-sized hash table might have positive performance
impact...

do you have comments?

roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Please welcome our Summer of Code Students

[Roman Divacky]

On Thu, Apr 24, 2008 at 12:45:48AM +0200, Konrad Jankowski wrote:
> Greetings to all in the FreeBSD community!
> My long-time dream of joining has come!

welcome! your project will help tons of people who are (attempting to)
run databases on fbsd ;)

thnx!

roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: strdup(NULL) supposed to create SIGSEGV?

[Roman Divacky]

> I think someone gave the reason I'm about to: trying to copy a NULL
> pointer means I have a bug somewhere earlier in my code that will
> eventually produce visibly wrong results - a segfault being such. The
> sooner that happens after the bug, the less code I have to search to
> find it, the better for me.

if only the fix was something else than

if (ptr != NULL)
   strdup(ptr);

:)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

use of MAXPATHLEN in kernel

[Roman Divacky]

hi

there's an awfully lot of code like

char foo[MAXPATHLEN];

in the kernel. either in functions (ie. allocated on stack during runtime)
or global variables. Most of the usage is without a good reason and only
wastes space.

should we do something about it? maybe an idea in projects/ideas webpage?

thnx

roman



pgpdr6hvpxNhc.pgp
Description: PGP signature

Re: Perforce and `p4 diff2' against the origin

[Roman Divacky]

On Sat, Apr 05, 2008 at 04:50:38PM +0200, Ed Schouten wrote:
> Hello everyone,
> 
> Because my mpsafetty project in Perforce is going quite well, I'm
> considering running some kind of cron job to generate nightly diffs, so
> other people (interested friends, colleagues and others) to test my
> work.
> 
> I've read `p4 help diff2' and it seems you can run the following
> command:
> 
>   p4 diff2 -b mpsafetty
> 
> Unfortunately this command just does a braindead diff against the latest
> FreeBSD vendor source, which is not useful in my case. I just want it to
> generate a diff against the version I integrated.
> 
> Is it possible to do this with Perforce?

this is what I use

p4 diff2 -du //depot/vendor/freebsd/src/sys/[EMAIL PROTECTED] 
//depot/projects/soc2007/rdivacky/linux_at/sys/...  | ~/awkdiff


you can adjust that to your needs
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: pfind() and the proc structure

[Roman Divacky]

On Tue, Apr 01, 2008 at 07:23:58AM -0700, Rao, Nikhil wrote:
> 
> Ok, I should have caught that :-( Another question - 
> Now that the PROC_LOCK on p is obtained the all_proc lock is released
> and the function returns, at this point can't the proc get deallocated ?

well.. thats why you hold the proc lock, isnt it? :)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: pfind() and the proc structure

[Roman Divacky]

On Mon, Mar 31, 2008 at 11:03:31PM -0700, Rao, Nikhil wrote:
> Hi List,
> 
> The pfind(..) (in kern_proc.c) function below returns the proc structure
> for the PID passed in
> 
> Say the thread that calls pfind() gets blocked at PROC_LOCK(p) (line 255
> below), in the meantime what prevents the process from exiting and
> deallocating the proc structure ? Maybe I am missing something simple or
> the answer requires knowledge of the mutex implementation.

thats what the allproc_lock is there for
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Updating vmware3 (and missing "avail_end" from /usr/include/machine/pmap.h)

[Roman Divacky]

On Sat, Mar 01, 2008 at 01:17:01PM +0100, Roman Divacky wrote:
> On Fri, Feb 29, 2008 at 01:29:23PM -0800, [EMAIL PROTECTED] wrote:
> > Hi all:
> > 
> > I'm trying to get vmware3 working on FreeBSD RELEASE 7.0 for i386
> > I've resolved every compilation problem except one:
> > the driver.c in vmware3 requires the "avail_end" variable
> > in 6.2's /usr/include/machine/pmap.h
> > but is missing from 7.0's /usr/include/machine/pmap.h
> > 
> > The vmware3 code goes like this:
> > 
> >   r = malloc(sizeof *r, M_DEVBUF, M_WAITOK);
> >   if (r == NULL) return ENOMEM;
> >   if (avail_end > ISA_DMA_BOUNCE_THRESHOLD)
> >  high = trunc_page(ISA_DMA_BOUNCE_THRESHOLD);
> >   else
> >  high = trunc_page(avail_end);
> > 
> > It turns out "avail_end" was removed from /usr/include/machine/pmap.h
> > by revision 1.125, whose commit message reads:
> > 
> >The global variable avail_end is redundant and only used once.
> >Eliminate it.  Make avail_start static to the pmap on amd64.
> >(It no longer exists on other architectures.)
> > 
> > So it appears that we can still get the value represented by
> > the old avail_end variable, but I don't know anything about the kernel
> > and I don't understand that comment.   Could some kind soul help me
> > decipher that so I can try to get vmware3 compilable again?
> 
> I think you can use "ptoa(Maxmem) - round_page(MSGBUF_SIZE)", the ptoa(Maxmem)
> being the thing written during dmesg as:
> 
> real memory  = 1039007744 (990 MB), I think its exported as hw.realmem sysctl
> 
> hope that helps.. let us know about your VMWare experiences!

erm.. what I meant to say what that hw.realmem - round_page(MSGBUF_SIZE) should 
work
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Updating vmware3 (and missing "avail_end" from /usr/include/machine/pmap.h)

[Roman Divacky]

On Fri, Feb 29, 2008 at 01:29:23PM -0800, [EMAIL PROTECTED] wrote:
> Hi all:
> 
> I'm trying to get vmware3 working on FreeBSD RELEASE 7.0 for i386
> I've resolved every compilation problem except one:
> the driver.c in vmware3 requires the "avail_end" variable
> in 6.2's /usr/include/machine/pmap.h
> but is missing from 7.0's /usr/include/machine/pmap.h
> 
> The vmware3 code goes like this:
> 
>   r = malloc(sizeof *r, M_DEVBUF, M_WAITOK);
>   if (r == NULL) return ENOMEM;
>   if (avail_end > ISA_DMA_BOUNCE_THRESHOLD)
>  high = trunc_page(ISA_DMA_BOUNCE_THRESHOLD);
>   else
>  high = trunc_page(avail_end);
> 
> It turns out "avail_end" was removed from /usr/include/machine/pmap.h
> by revision 1.125, whose commit message reads:
> 
>The global variable avail_end is redundant and only used once.
>Eliminate it.  Make avail_start static to the pmap on amd64.
>(It no longer exists on other architectures.)
> 
> So it appears that we can still get the value represented by
> the old avail_end variable, but I don't know anything about the kernel
> and I don't understand that comment.   Could some kind soul help me
> decipher that so I can try to get vmware3 compilable again?

I think you can use "ptoa(Maxmem) - round_page(MSGBUF_SIZE)", the ptoa(Maxmem)
being the thing written during dmesg as:

real memory  = 1039007744 (990 MB), I think its exported as hw.realmem sysctl

hope that helps.. let us know about your VMWare experiences!

roman

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: firefox flash plug in woes

[Roman Divacky]

> i wanna goto youtube! {:}  i already have firefox installed, is there
> a special port for linux firefox?  i better deinstall my existing firefox?

swfdec (in ports) handles youtube (and a lot of other things) just fine
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: syscall linux_getdents() trouble

[Roman Divacky]

On Mon, Jan 07, 2008 at 11:34:51AM +0300, sam wrote:
> program-test (experimental) for testing syscall linux_getdents() 
> http://cs.udmvt.ru/files/temp/linux_dbg.tar.bz2
> includes:
> * temp/ - test_dir with files (special for crash situation)
> * linux_getdents.c - source of program-test
> * linux_getdents_static - binary exec file, staticaly compiled on Linux 
> Debian 4.0 Etch
> * linux_getdents_dynamic - binary exec file, dynamicaly compiled on 
> Linux Debian 4.0 Etch
> 
> - test failed on systems: FreeBSD 6.3-PRERELEASE with port 
> linux_base-fc4, FreeBSD 8.0-CURRENT with port linux_base-fc4;
> - test passed on Linux Debian 4.0 Etch
> 
> Trouble: syscall linux_getdents() don`t stable work
> 
> Trouble Description:
> http://lists.freebsd.org/pipermail/freebsd-emulation/2007-September/thread.html
> topic subject: linuxolator problem on i386
> http://www.freebsd.org/cgi/query-pr.cgi?pr=117010
> 
> please help, any solution?

unless someone else looks at it it wont be done anytime soon as I dont have
much time. I'll try to find some but I cant promise anything.

some other volunteer? (so I can focus on other things)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Before & After Under The Giant Lock

[Roman Divacky]

On Sun, Nov 25, 2007 at 02:41:35PM -0600, Stephen Montgomery-Smith wrote:
> 
> 
> On Sun, 25 Nov 2007, Robert Watson wrote:
> 
> >
> >In FreeBSD 8, I expect we'll see a continued focus on both locking 
> >granularity and improving opportunities for kernel parallelism by better 
> >distributing workloads over CPU pools.  This is important because the 
> >number of cores/chip is continuing to increase dramatically, so MP 
> >performance is going to be important to keep working on.  That said, the 
> >results to date have been extremely promising, and I anticipate that we 
> >will continue to find ways to better exploit multiprocessor hardware, 
> >especially in the network stack.
> >
> 
> I just want to add my 2 cents, that my recent experience with FreeBSD MP 
> has been extremely positive.  I tend to use highly CPU bound MP programs, 
> typically lots and lots of floating point operations.  It used to be that 
> Linux beat FreeBSD hands down - now FreeBSD seems to have a slight edge! 
> Basically my program runs about twice as fast when I run two threads as 
> opposed to one - I cannot see doing any better than that!

pure computation does not need kernel operations most of the time.. ie. 
multi-threading kernel wont help much ;)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: a strange/stupid question

[Roman Divacky]

On Sat, Nov 24, 2007 at 03:33:24AM +, Aryeh Friedman wrote:
> Where do I find the main() [and/or other entery point] for the
> kernel I tend to understand stuff better if I follow the flow of
> exec from the start

note that "kernel" as such does not "exist". its threads/processes running
code in kernel space.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: modify syscall nr on-the-fly

[Roman Divacky]

On Thu, Aug 23, 2007 at 04:07:41PM +0400, Yuriy Tsibizov wrote:
> > I'm trying to get user-mode Linux to run under FreeBSD Linux emulation (on
> > i386).
> 
> Ivan,
> 
> current status & patches are on http://chibis.persons.gfk.ru/linux/.

what fbsd version are you using? if 7.x is it with 2.4 emulation or 2.6 
emulation?
do you have /compat/linux/proc and sys mounted?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: User-mode Linux (Was: modify syscall nr on-the-fly)

[Roman Divacky]

here is a little review of mine... just little suggestions.

Index: i386/i386/trap.c
===
RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v
retrieving revision 1.307
diff -u -r1.307 trap.c
--- i386/i386/trap.c26 Jul 2007 15:32:55 -  1.307
+++ i386/i386/trap.c22 Aug 2007 08:53:19 -
@@ -1004,6 +1004,32 @@
 
PTRACESTOP_SC(p, td, S_PT_SCE);
 
+   if (__predict_false(p->p_sysent->sv_name[0]=='L')) {

please use __predict_true(p->p_sysent != &elf_linux_sysvec)

+   if (code != frame->tf_eax) {
+   printf("linux sysctl patched: code %d return eax %d\n", 
code, frame->tf_eax);
+   /* retry */
+   code = frame->tf_eax;
+   
+   if (p->p_sysent->sv_prepsyscall)
+   /*
+* The prep code is MP aware.
+*/
+   (*p->p_sysent->sv_prepsyscall)(frame, 
args, &code, ¶ms);
+   /* else should always be null */
+
+   if (p->p_sysent->sv_mask)
+   code &= p->p_sysent->sv_mask;

the sv_mask should be removed.. dont use it in your code. its entirely 
pointless when dealing
with Linux binaries

+   if (code >= p->p_sysent->sv_size)
+   callp = &p->p_sysent->sv_table[0];
+   else
+   callp = &p->p_sysent->sv_table[code];
+
+   narg = callp->sy_narg;
+   /* retry ends */
+   }
+   }
+
AUDIT_SYSCALL_ENTER(code, td);
error = (*callp->sy_call)(td, args);
AUDIT_SYSCALL_EXIT(error, td);
Index: i386/linux/linux_ptrace.c
===
RCS file: /home/ncvs/src/sys/i386/linux/linux_ptrace.c,v
retrieving revision 1.17
diff -u -r1.17 linux_ptrace.c
--- i386/linux/linux_ptrace.c   22 Feb 2006 18:57:49 -  1.17
+++ i386/linux/linux_ptrace.c   22 Aug 2007 09:27:01 -
@@ -78,6 +78,7 @@
 #define PTRACE_SETFPXREGS  19
 
 #define PTRACE_SETOPTIONS  21
+#define PTRACE_O_TRACESYSGOOD  0x0001
 
 /*
  * Linux keeps debug registers at the following
@@ -95,6 +96,10 @@
return ((signum == SIGSTOP)? 0 : signum);
 }
 
+struct linux_pt_lreg {
+   l_long reg[19];
+};
+
 struct linux_pt_reg {
l_long  ebx;
l_long  ecx;
@@ -103,17 +108,17 @@
l_long  edi;
l_long  ebp;
l_long  eax;
-   l_int   xds;
-   l_int   xes;
-   l_int   xfs;
-   l_int   xgs;
+   l_long  xds;
+   l_long  xes;
+   l_long  xfs;
+   l_long  xgs;
l_long  orig_eax;
l_long  eip;
-   l_int   xcs;
+   l_long  xcs;
l_long  eflags;
l_long  esp;
-   l_int   xss;
-};
+   l_long  xss;
+} __packed;

why is this necessary? how does it affect amd64 linux32 emulator?
 
 /*
  *   Translate i386 ptrace registers between Linux and FreeBSD formats.
@@ -247,6 +252,7 @@
struct linux_pt_reg reg;
struct linux_pt_fpreg   fpreg;
struct linux_pt_fpxreg  fpxreg;
+   struct linux_pt_lreglreg;
} r;
union {
struct reg  bsd_reg;
@@ -429,20 +435,21 @@
 * as necessary.
 */
if (uap->addr < sizeof(struct linux_pt_reg)) {
+   if (uap->addr == (11 << 2)) /* orig_eax */
+   uap->addr = (6 << 2); /* eax */
+   
error = kern_ptrace(td, PT_GETREGS, pid, &u.bsd_reg, 0);
if (error != 0)
break;
 
map_regs_to_linux(&u.bsd_reg, &r.reg);
if (req == PTRACE_PEEKUSR) {
-   error = copyout((char *)&r.reg + uap->addr,
-   (void *)uap->data, sizeof(l_int));
+   error = 
copyout((l_long*)(&r.lreg.reg[uap->addr>>2]),
+   (void *)uap->data, sizeof(l_long));
break;
}
 
-   *(l_int *)((char *)&r.reg + uap->addr) =
-   (l_int)uap->data;
-
+   r.lreg.reg[uap->addr>>2] = (l_long)uap->data;
map_regs_from_linux(&u.bsd_reg, &r.reg);
error = kern_ptrace(td, PT_SETREGS, pid, &u.bsd_reg, 0);
}
@@ -470,11 +477,34 @@
error = kern_ptrace(td, PT_S

Re: linuxolator problem on amd64

[Roman Divacky]

> Take a look at /usr/ports/UPDATING : 20070327:
>  AFFECTS: users of emulators/linux_base-fc6
>  AUTHOR: [EMAIL PROTECTED]
> 
>  ATTENTION! The port is experimental for now. Use it at your own risk. This
>  port may be used only with 7-CURRENT and compat.linux.osrelease=2.6.16.
> 
> So it's not just a SoC project :)

well. actually it was implemented during a SoC so it can be considered kind of 
a SoC
project ;)

anyway, the current status is that 7.0R will contain roughly working 2.6 
emulation
while 8-current will have fine working 2.6 emulation turned on default.

so things are slowly improving ;)

roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: linuxolator problem on amd64

[Roman Divacky]

On Wed, Aug 22, 2007 at 01:36:20AM +0200, Pieter de Goeje wrote:
> On Tuesday 21 August 2007, sam wrote:
> > Hi, all.
> >
> > i am try runing Enemy Territory: Quake Wars server
> > (links on http://weec.ovl.ru/csdivision/index.php?topic=662.0 )
> >
> > # uname -rms
> > FreeBSD 6.2-STABLE amd64
> >
> > # mount | grep linproc
> > linprocfs on /usr/compat/linux/proc (linprocfs, local)
> >
> > # cat run.sh
> > #!/bin/sh
> > cd `dirname $0`
> > export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:."
> > exec ./etqwded.x86 "$@"
> >
> > # ./run.sh
> > cannot set up thread-local storage: cannot set up LDT for thread-local
> > storage
> TLS for Linux programs only work on i386 or -current amd64, so either 
> downgrade to 32bits FreeBSD or upgrade to FreeBSD 7, or find a version of the 
> program that doesn't use TLS (non threaded version).

I think the program is trying to set up "TLS" using user LDT. not the GDT 
segment
TLS Linux 2.6 uses. ie. upgrading to 7.x etc. wont help
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: questions on nonsleepable lock

[Roman Divacky]

On Wed, Aug 15, 2007 at 05:10:48PM +0800, Nex Mon wrote:
> thanks for your reply.
> 
> i didn't use WITNESS. it is disabled.
> 
> is their a list a list of which locks are sleepable and non-sleepable
> in FreeBSD6.2? is sleeping triggered by a call to "sleep", IO operation
> or a result of context switching by kernel?

all locks except sx and Giant are nonsleepable, sleeping can be triggered
by calling foo_sleep() and/or by calling a sleeping function (like io etc.)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: questions on nonsleepable lock

[Roman Divacky]

On Wed, Aug 15, 2007 at 02:27:56PM +0800, Nex Mon wrote:
> Hello All,
> 
> Can someone point me out or explain the technical details of this kernel
> panic:
> 
> sleeping thread (tid 100093, pid 2676) owns nonsleepable lock
> panic: sleeping thread

it just says that some thread owns a nonsleepable lock and went sleeping.
are you using WITNESS?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

strange KASSERT in _sleep()

[Roman Divacky]

hi

tsleep() maps to _sleep() with lock = NULL,

the _sleep() contains this:

  KASSERT(timo != 0 || mtx_owned(&Giant) || lock != NULL ||
  ident == &lbolt, ("sleeping without a lock"));


which simplifies for tsleep(foo, ...) where foo != lbolt to
"timo != 0 || mtx_owned(&Giant)"

why do I have to hold Giant or have timo != 0 when calling tsleep?

thnx for explanation

roman

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: p_vmspace in syscall

[Roman Divacky]

> Ok, syscall function passed a proc* as arguments, I don't know where

this does not make any sense... userland processes have no way to
determine where a proc is stored...

what exactly are you trying to achieve?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: getCWD in kernel space

[Roman Divacky]

On Sat, Jun 30, 2007 at 03:24:17PM +, Eren Erdemli wrote:
> Hello hackers,
> 
> Sorry to disturb you's but I have a question and would like to know if you
> can assist me.
> 
> I am new to freebsd programing and I am trying to get the current working
> directory of  the curthread.
> 
> I have hook on to the sys calls and redirected the mkdir
> 
> my_mkdir(struct thread *p, (void*) uap)
> {
>   mkdir_args = .
>   
>  getCWD()???
> }


curthread->td_proc->p_fd->fd_cdir is a vnode of cwd
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: CPUTYPE in general - was Re: Which CPUTYPE for a dualcore Xeon on AMD64

[Roman Divacky]

> In general, how does one decide which CPUTYPE to use?  The connection 
> between the options for CPUTYPE and the output of dmesg is not so 
> obvious to me.  I looked at the features advertised by dmesg (which in 
> my case included SSE3) and then reverse engineered bsd.cpu.mk to figure 
> out I should be using "prescott," but I am hoping I figured it out the 

I would not judge only by instructions like SSE etc. ins scheduling etc.
plays key role as well. 

you should know what cpu you bought, or just use cpuid (found in ports)
and determine what cpu you have.

on -current you can set _native_ or native (dont remember) and gcc will
choose itself... ;)

roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Making sense of ktrace(1) output

[Roman Divacky]

>Unfortunately I have to profile all of the source up the tree to 
> create profiled symbols, and I'm running into some issues profiling 
> liblegacy.
>Does anyone have any hints for getting around that, or just 
> profiling all of the relevant libs?

I think you can build fbsd with profiling of all libraries (in base) and
run it like that...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Making sense of ktrace(1) output

[Roman Divacky]

On Mon, Jun 18, 2007 at 01:55:01AM -0700, Garrett Cooper wrote:
> Peter Jeremy wrote:
> >On 2007-Jun-18 00:39:44 -0700, Garrett Cooper <[EMAIL PROTECTED]> 
> >wrote:
> >  
> >>However, I was able to get ktrace output. The only problem is that 
> >>ktrace(1) apparently outputs only in binary, instead of plaintext output. 
> >>Can I convert it to plaintext somehow and process it?
> >>
> >
> >kdump(1)
> >
> >  
> grazi to all that replied -- that did the trick :).
> 
> Now, note to self.. never ever do analysis on something so large as 
> pkg_add thunderbird. Really, really bad idea :)..
> 
> I'll make up some Perl scripts, produce some histograms, and see if I 
> can better trace down this bottleneck.

well.. instead of using ktrace I'd suggest building profiled pkg_add
and see that way where the time is spent. ktrace is great if you dont
have the source code... but you do :)

roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH]: acct_process() locking and exit1()

[Roman Divacky]

On Thu, Jun 14, 2007 at 09:54:39AM +0200, Roman Divacky wrote:
> hi
> 
> currently in exit1() we call acct_process() with Giant held.
> I looked at the code and I think this is because of tty need
> for Giant locking. Because of this we have to release process limit 
> in a separate PROC_LOCK()/UNLOCK() block.
> 
> my just-to-look-at patch does this
> 
> 1) moves the acct_process() in exit1() out of Giant locked block (upward)
> 2) acquires Giant in the acct_process() around tty handling
> 3) moves the p->p_limit to a different PROC_LOCK/UNLOCK block (upward)
> 
> the result is saving 2 proc mtx operations in exit1()
> 
> can you look at it and tell me if its correct or wrong or something like that?
> 
> if it's correct is it worth committing? saving two mtx operations is a nice 
> thing :)

erm... two bugs ;) "saving two mtx operations..." in the typical case of 
accounting
NOT being enabled.

and forgot to show the patch ;) it's here

www.vlakno.cz/~rdivacky/kern_acct.patch
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[PATCH]: acct_process() locking and exit1()

[Roman Divacky]

hi

currently in exit1() we call acct_process() with Giant held.
I looked at the code and I think this is because of tty need
for Giant locking. Because of this we have to release process limit 
in a separate PROC_LOCK()/UNLOCK() block.

my just-to-look-at patch does this

1) moves the acct_process() in exit1() out of Giant locked block (upward)
2) acquires Giant in the acct_process() around tty handling
3) moves the p->p_limit to a different PROC_LOCK/UNLOCK block (upward)

the result is saving 2 proc mtx operations in exit1()

can you look at it and tell me if its correct or wrong or something like that?

if it's correct is it worth committing? saving two mtx operations is a nice 
thing :)

thank you

roman

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: file(1) cannot detect UFS2?

[Roman Divacky]

> Now there's only the matter of importing it :)
> 

you mean... like was done 2 weeks ago? :)


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: file(1) cannot detect UFS2?

[Roman Divacky]

On Sun, Jun 10, 2007 at 12:41:31AM +0200, Ivan Voras wrote:
> Hi!
> 
> I'm trying to use file(1) to detect file system type on partitions, and
> so far it's working for any file system I've cared to try (the usual MS
> and Linux list) *except* UFS2.
> 
> Detecting UFS1 works, though much more verbosely than it needs to be,
> but UFS2 isn't detected at all.
> 
> I'd like to ask someone familiar with UFS2 to take a quick peak and add
> the appropriate rules to the file(1) magic database, if anyone's interested.
> 
> At the very least, I need someone to commit this patch:

well... yeah but not to freebsd :) I guess you want to  forward the patch 
upstream
to the maintainers of file.

thnx for the work though
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Looking for speed increases in "make index" and pkg_version for ports

[Roman Divacky]

On Mon, May 28, 2007 at 11:34:24AM -0500, Stephen Montgomery-Smith wrote:
> Jeremy Chadwick wrote:
> >On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote:
> >> I have been thinking a lot about looking for speed increases for "make 
> >> index" and pkg_version and things like that.  So for example, in 
> >> pkg_version, it calls "make -V PKGNAME" for every installed package. Now 
> >> "make -V PKGNAME" should be a speedy operation, but the make has to load 
> >> in and analyze bsd.port.mk, a quite complicated file with about 200,000 
> >> characters in it, when all it is needing to do is to figure out the 
> >> value of the variable PKGNAME.
> >
> >I have a related question, pertaining to "make all-depends-list" and the
> >utter atrocity that is the make variable ALL-DEPENDS-LIST.  If you don't
> >know what it is, look for ^ALL-DEPENDS-LIST around line 5175, in
> >bsd.ports.mk.
> 
> I posted this to [EMAIL PROTECTED], but now I am realizing that it is 
> [EMAIL PROTECTED] that gets more responses.  Anyway, here is a 
> multithreaded program "all-depends-list" that can get you double the 
> speed on dual processor systems, and even some small speed gains on 
> single processor systems.  E.g.
> 
> all-depends-list /usr/ports/x11/xorg
> 
> http://www.math.missouri.edu/~stephen/all-depends-list.c

btw.. stehpen, when are you getting a commit bit? :) I certainly hope that soon 
enough ;)

roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))

[Roman Divacky]

> cyclic dependancies in it!), but still, in itself, I think the choice of
> Ruby isn't performance-critical.

ruby2.0 will come with a virtual machine which should speed up things. ruby2.0
is expected "soon enough" (2008?)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [ANN] unionfs patchset-19-20070504 release, it is now MPSAFE and transparent mode as default

[Roman Divacky]

> Hi,
>   So far I've tested it under -current, in my diskless env. where
> /etc & /compat/linux are unionfs'ed with a mfs, and so all seems OK.

there's an XXX in the linuxulator code saying:

XXX Untested vs. mount -o union; probably does the wrong thing.

can you confirm that it works ok with unionfs from daichi?

thnx

roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: prebind support status

[Roman Divacky]

On Sat, Apr 14, 2007 at 05:24:16PM +0300, Tyrael wrote:
> Has anyone started working on porting 'prebind' from OpenBSD?
> 
> Has there been any discussion over this matter; as to how much work  this
> would require ?
> I would be interested into looking over this and see if i can implement it,
> so any info any of you has would help a lot

maybe if someone posted some interesting benchmark numbers people would care
a little more ;)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"