Re: [patch] SUBDIR_OVERRIDE `optimization'

[Ruslan Ermilov]

On Fri, Jul 09, 2010 at 07:56:37AM -0700, Garrett Cooper wrote:
 (Let's try this again with the right email address)
     Something simple that I noticed a while back when I was reviewing
 the Makefile.inc1 code. The SUBDIR_OVERRIDE code is executed after the
 conditional feature checks, which sets the value of SUBDIRS to the
 user defined value. So instead of going through the conditionals, one
 could just cut to the chase and set SUBDIRS to SUBDIRS_OVERRIDE,
 otherwise detect the conditional directories to include in
 Makefile.inc1.
 Thanks!
 -Garrett
 
 Index: Makefile.inc1
 ===
 --- Makefile.inc1 (revision 209684)
 +++ Makefile.inc1 (working copy)
 @@ -41,6 +41,9 @@
  # use that new version.  And the new (dynamically-linked) /bin/sh
  # will expect to find appropriate libraries in /lib and /libexec.
  #
 +.if defined(SUBDIR_OVERRIDE)
 +SUBDIR=  ${SUBDIR_OVERRIDE}
 +.else
  SUBDIR=  share/info lib libexec
  SUBDIR+=bin
  .if ${MK_GAMES} != no
 @@ -79,8 +82,6 @@
  .endif
  .endfor
 
 -.if defined(SUBDIR_OVERRIDE)
 -SUBDIR=  ${SUBDIR_OVERRIDE}
  .endif
 
  .if defined(NOCLEAN)

SUBDIR_OVERRIDE is mainly for FreeBSD src/ builders (to quickly
check with buildworld a particular bit of a tree), and is thus
rarely used, so this change would be an optimization for the
uncommon case.  Having said that, I don't mind if you commit it,
if you like.


Cheers,
-- 
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
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] Use _SIG_VALID macro in ddb/db_command.c

[Garrett Cooper]

Spotted this really minor item that I figured could be converted over
to _SIG_VALID in ddb:

Index: ddb/db_command.c
===
--- ddb/db_command.c(revision 206173)
+++ ddb/db_command.c(working copy)
@@ -633,7 +633,7 @@
if (!db_expression(pid))
DB_ERROR((Missing process ID\n));
db_skip_to_eol();
-   if (sig  1 || sig  _SIG_MAXSIG)
+   if (!_SIG_VALID(sig))
DB_ERROR((Signal number out of range\n));

/*

considering that the above range and _SIG_VALID are complementing checks.

Thanks,
-Garrett
___
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: strange problem with int64_t variables

[pluknet]

On 11 July 2010 18:58, Gabor Kovesdan ga...@freebsd.org wrote:
 Em 2010.07.11. 16:54, Dimitry Andric escreveu:

 On 2010-07-11 16:46, Gabor Kovesdan wrote:


 I have two int64_t variables in kernel code, first is stored internally
 and the second one is passed from a syscall argument. When I print them
 with printf %lld modifier, the internal one behaves correctly but the
 other one I pass from a syscall has a corrupted value. If I pass 1, it
 prints out 3735348794091372545. I'm not doing anything special with it
 just reading it out from the struct that was generated with make sysent.


 Since 3735348794091372545 is 0x33d69ff1, it looks like the upper
 word got corrupted somehow.  Maybe some part of it got non-atomically
 assigned?  Maybe the wrong word was read?  It is hard to tell without
 code...  :)


 Userland syscall calling:

 killjob(getjid(), SIGINT);  //getjid() returns 1 this case, whose type is
 jid_t


Looking at getjid() impl, I see you're trying to put jid_t into the
one register_t
which are 64-bit vs 32-bit capable respectively.
You need to cast so you put 64-bit into two 32-bit as done for e.g. lseek().

-- 
wbr,
pluknet
___
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] Use _SIG_VALID macro in lib/libthr/thread/thr_sig.c

[Garrett Cooper]

Found another item that could be converted over to _SIG_VALID in
libthr's thr_sig.c this time.
Thanks,
-Garrett

Index: lib/libthr/thread/thr_sig.c
===
--- lib/libthr/thread/thr_sig.c (revision 206173)
+++ lib/libthr/thread/thr_sig.c (working copy)
@@ -194,7 +194,7 @@
 _sigaction(int sig, const struct sigaction * act, struct sigaction * oact)
 {
/* Check if the signal number is out of range: */
-   if (sig  1 || sig  _SIG_MAXSIG || sig == SIGCANCEL) {
+   if (!_SIG_VALID(sig) || sig == SIGCANCEL) {
/* Return an invalid argument: */
errno = EINVAL;
return (-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

Re: *sigpause hanging on 8.x+

[Kostik Belousov]

On Sun, Jul 11, 2010 at 07:17:27PM -0400, Alexander Kabaev wrote:
 On Sun, 11 Jul 2010 15:59:05 -0700
 Garrett Cooper yaneg...@gmail.com wrote:
 
   +       if (!_SIG_VALID(how))
   +               return (-EINVAL);
 
 -EINVAL? Smells too much of Linux, try returning EINVAL instead.
Mmm,
if (!_SIG_VALID(how)) {
errno = EINVAL;
return (-1);
}
This is libc.


pgpB9z3XudJ0N.pgp
Description: PGP signature

[PATCH] Fix typos in bsd.port.mk and minor logic improvements

[Garrett Cooper]

This is a change I made locally that I figured would be helpful because it:
a. Fixes typos.
b. Improves branch flow in a few spots.
c. Doesn't assume that all strings that come back from pkg_install
are empty (this is what's assumed today).
Thanks,
-Garrett

--- /usr/ports/Mk/bsd.port.mk   2010-06-04 01:09:17.0 -0700
+++ bsd.port.mk 2010-07-09 08:01:08.0 -0700
@@ -20,7 +20,7 @@
 #
 # DO NOT COMMIT CHANGES TO THIS FILE BY YOURSELF, EVEN IF YOU DID NOT GET
 # A RESPONSE FROM THE MAINTAINER(S) WITHIN A REASONABLE TIMEFRAME! ALL
-# UNAUTHORISED CHANGES WILL BE UNCONDITIONALLY REVERTED!
+# UNAUTHORIZED CHANGES WILL BE UNCONDITIONALLY REVERTED!

 FreeBSD_MAINTAINER=port...@freebsd.org

@@ -3968,7 +3968,7 @@
prfx=`${PKG_INFO} -q -p $${p} 
2 /dev/null | ${SED} -ne
'1s|^...@cwd ||p'`; \
if [ x${PREFIX} = x$${prfx} 
]; then \
df=`${PKG_INFO} 
-q -f $${p} 2 /dev/null | ${GREP} -v ^@ |
${COMM} -12 - ${TMPPLIST}`; \
-   if [ -n 
$${df} ]; then \
+   if [ -n 
$${df:-} ]; then \

found_package=$${p}; \

break; \
fi; \
@@ -4551,7 +4551,7 @@
check_name=`${ECHO_CMD} $${p} | ${SED} -e 
's/-[^-]*$$//'`; \
if [ $${check_name} = ${PKGBASE} ]; then \
prfx=`${PKG_INFO} -q -p $${p} 2 
/dev/null | ${SED} -ne '1s|^...@cwd ||p'`; \
-   if [ x${PREFIX} = x$${prfx} ]; then 
\
+   if [ x${PREFIX} = x$${prfx:-} ]; 
then \
${ECHO_MSG} ===   
Deinstalling $${p}; \
${PKG_DELETE} -f $${p}; 
\
else \
@@ -4583,7 +4583,7 @@
for oldpkgorigin in $$(${GREP} |${PKGORIGIN}| ${PORTSDIR}/MOVED |
${CUT} -f 1 -d '|' | ${SORT} -u); do \
deinstall_names=$${deinstall_names} $$(${PKG_INFO} -q -O
$${oldpkgorigin}); \
done; \
-   if [ -n $${deinstall_names} ]; then \
+   if [ -n $${deinstall_names:-} ]; then \
for d in $${deinstall_names}; do \
${ECHO_MSG} ===   Deinstalling $${d}; \
${PKG_DELETE} -f $${d}; \
@@ -5129,7 +5129,7 @@
-e 's/=/=gt=/; s//=ge=/; 
s/=/=lt=/; s//=le=/' \
-e 's/=gt=//; s/=ge=/=/; 
s/=lt=//; s/=le=/=/'`; \
pkg_info=`${PKG_INFO} -E 
$$inverse_dep || ${TRUE}`; \
-   if [ $$pkg_info !=  ]; then \
+   if [ $${pkg_info:-} !=  ]; then \
${ECHO_MSG} ===   Found 
$$pkg_info, but you need to upgrade
to $$prog.; \
exit 1; \
fi; \
@@ -5465,10 +5465,9 @@
if [ ${CHILD_DEPENDS} ]; then \
installed=$$(${PKG_INFO} -qO ${PKGORIGIN} 2/dev/null || \
${TRUE}); \
-   if [ $$installed ]; then \
+   if [ -n $${installed:-} ]; then \
break; \
-   fi; \
-   if [ -z $$installed ]; then \
+   else \
installed=${PKGNAME}; \
fi; \
for pkgname in $$installed; do \
@@ -5511,16 +5510,15 @@
while [ $$\# -gt 1 ]; do \
if [ ! -d ${PORTSDIR}/$$2 ]; then \
shift; \
-   continue; \
-   fi; \
-   if [ $$dir = $$2 ]; then \
+   elif [ $$dir = $$2 ]; then \
${ECHO_CMD} $$1:$$dir; \
if [ -e ${PKG_DBDIR}/$$1/+CONTENTS -a -z
${EXPLICIT_PACKAGE_DEPENDS} ]; then \
packagelist=$$packagelist 
${PKG_DBDIR}/$$1/+CONTENTS; \
fi; \
break; \
+   else \
+   shift 2; \
fi; \
-   shift 2; \
done; \
done; \
[ -z $$packagelist ] || ${AWK} -F '( |:)' 

TCP over UDP

[Sergey Babkin]

Hi guys,

I've got this idea, and I wonder if anyone has done it already,
and if not then why. The idea is to put the TCP logic over UDP.

I've done some googling and all I've found is some academical
user-space implementations of TCP that actually try to interoperate
with real TCP. What I'm thinking about is different. It's
to use the TCP-derived logic as a portable library that would
do the good flow control, retransmitting, delivery confirmations 
etc over UDP.

Basically, every time you use UDP, you've got to reinvent your
own retransmission and reliability protocol. And these protocols
are typically no good at all, as the story with NFS switching
from UDP to TCP and improving the performance shows. At the same
time TCP provides a very good transport control logic, so why not
just reuse this logic in a library to solve the UDP issues once
and for all?

Then of course, why not just use TCP? The problem of TCP is that
it's expensive. It uses the kernel memory for its contexts.
It also requires a file descriptor per each connection. The file
descriptors are an expensive resource, and besides, even if
the limit is raised, there is the issue with historic select()
fd_set allocating only 1024 bits and nobody checking for the
overflow. Even if your own code is carefully designed to avoid using
select() at all and/or create large enough bitmasks, it could
always happen to use some stupid library that doesn't do that 
and causes the interesting one-bit memory corruptions.

Moving the connection logic to the user space makes the connections
cheap. A hundred bytes or so per connection state is no big
deal, you can easily create a million of these connections to
the same process. All the state stays in the user-space pageable
memory. Well, all of them sending data at the same time
might not work so well, but caching a large number of currently
inactive connections becomes cheap. Think of XMLRPC or SOAP
or anything else over HTTP reusing the same TCP connection for
multiple sequential requests. Now there is a painful balance 
of inactivity timeouts: make them too long and you
overload the server, make them too short and the connections
get dropped all the time. The cheap connections would allow
to keep the much longer timeouts.

Then there are other interesting possibilities arising from the easy
access to the protocol state. The underlying datagramness can be 
exposed to the top level, and this immediately gives the transactional
TCP. Or we could look at the state and find out if the data has
been actually delivered to and confirmed by the other side.
Or we can even drop the inactive connections at the server without
notifying the client. Then if the client sends more requests on this
connection, the server could semi-transparently re-establish it
(OK, this would require an extension from TCP). Or we can do
the better keep-alives, not the TCP's hour-long ones, but 
something within a few seconds (would not work too well with
millions of connections, but it's a different use case where
we want to detect the lost peer fast). Or having sub-channels,
each with its own sequence number. If the data gets transferred
over 100 parallel logical connections, few bytes at a time for
each of them, combining the whole bunch into one datagram would
be much more efficient tahn sending 100 datagrams. These are just 
the ideas off the bat, there's got to be more of these interesting
usages.

It all looks like such an obviously good idea, that I wonder,
why didn't anyone else try it before? Or have they tried
it and found that it's not such a good idea after all?

-SB
___
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: elf obj load: skip zero-sized sections early

[Jeff Roberson]

On Sun, 11 Jul 2010, Andriy Gapon wrote:



[oops, sorry, this is not a dup - corrected some omissions/mistakes]

on 11/07/2010 14:54 Andriy Gapon said the following:

For completeness, here is a patch that simply drops the inline assembly and the
comment about it, and GCC-generated assembly and its diff:
http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch
http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s
http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff

As was speculated above, the only thing really changed is section alignment
(from 128 to 4).


After making the above analysis I wondered why we require set_pcpu section
alignment at all.  After all, it's not used as loaded, data from the section
gets copied into special per-cpu memory areas.  So, logically, it's those areas
that need to be aligned, not the section.


I appreciate your analysis but I don't understand the motivation for 
changing working code.


Jeff



svn log and google quickly pointed me to this excellent analysis and explanation
by bz (thanks again!):
http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff

Summary: this alignment is needed to work around a bug in GNU binutils ld for
__start_SECNAME placement.

As explained by bz, ld internally generates an equivalent of the following
linker script:
...
__start_pcpu_set = ALIGN(NN);
pcpu_set : {
...
}
__stop_pcpu_set = .;

Where NN is an alignment of the first _input_ pcpu_set section found in
whichever .o file happens to be first.  Not the resulting alignment of pcpu_set
_output_ section.
Alignment requirement of input sections is based on largest alignment
requirement of section's members.  So if section is empty then the required
alignment is 1.  Alignment of output section, if not explicitly overridden e.g.
via linker script, is the largest alignment of the corresponding input sections.

I think that the problem can be fixed by making ld define __start_SECNAME like
follows:
...
pcpu_set : {
__start_pcpu_set = ABSOLUTE(.);
...
}
__stop_pcpu_set = .;

This way __start_SECNAME would always point to the actual start of the output
section.

Here's a patch that implements the idea:
http://people.freebsd.org/~avg/dpcpu/ld.start_sec-alignment.patch

This is similar to what was done upstream:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?r1=1.306r2=1.307cvsroot=srcf=h
The code is quite different there, and approach is somewhat different, but the
idea is the same - place __start_SECNAME inside the section, not outside it.

My testing shows the expected results.
What do you think?

--
Andriy Gapon


___
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: strange problem with int64_t variables

[Gabor Kovesdan]

Em 2010.07.12. 9:00, pluknet escreveu:

Looking at getjid() impl, I see you're trying to put jid_t into the
one register_t
which are 64-bit vs 32-bit capable respectively.
You need to cast so you put 64-bit into two 32-bit as done for e.g. lseek().
   
Thanks for pointing this out, probably this was the problem, I'll try 
later because for now, I switched to 32-bit jid_t and that part works 
but there's other similar problem now:


+int
+setjlimit(struct thread *td, struct setjlimit_args *uap)
+{
+   struct jobentry *jp;
+
+   /* sanity check */
+   if (uap-resource= JLIMIT_NLIMITS) {
+   td-td_retval[0] = -1;
+   return (EINVAL);
+   }

...

The rest is just generated code with make sysent.

I call this with resource parameter set to JLIMIT_NUMPROC (whose value 
is 3) and then inside the function it is seen as 869787392, so I always 
get EINVAL. In this case resource is just a normal int so I don't know 
what's going wrong.


Gabor

___
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: TCP over UDP

[Dirk-Willem van Gulik]

On 10 Jul 2010, at 13:05, Sergey Babkin wrote:

 I've got this idea, and I wonder if anyone has done it already,
 and if not then why. The idea is to put the TCP logic over UDP.

Have you looked at T/TCP [1,2,3] ?

Dw

1: http://www.manpages.info/freebsd/ttcp.4.html
2: http://en.wikipedia.org/wiki/T/TCP
3: 
http://people.freebsd.org/~andre/Optimizing%20the%20FreeBSD%20IP%20and%20TCP%20Stack%20-%20Presentation.pdf___
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: kernel patch needed for wine?

[Tijl Coosemans]

On Wednesday 30 June 2010 01:54:11 Sam Fourman Jr. wrote:
 Last Tuesday blizzard release World of Warcraft 3.3.5, and with this
 patch World of warcraft stopped working in FreeBSD 8.1 amd64, it
 crashes right after login.

 I have been playing World of Warcraft on FreeBSD amd64 since December
 of 2009 using the beta Nvidia 64bit drivers and this wine how-to

 http://wiki.freebsd.org/Wine#head-6963d527c173e57b1567e881305b544d33435b6d

 I can verify that on PCBSD 8.1 RC1 32bit World of warcraft works post
 3.3.5 so far as I can tell it is only broken on amd64.

Could you give the attached patch a try?

cd /usr/src
patch -p1  /path/to/patch-amd64-dr7
make buildkernel installkernel
diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S
index cfb4204..6b5c663 100644
--- a/sys/amd64/amd64/cpu_switch.S
+++ b/sys/amd64/amd64/cpu_switch.S
@@ -243,13 +243,13 @@ store_dr:
movq%dr2,%r13
movq%dr3,%r12
movq%dr6,%r11
-   andq$0xfc00, %rax   /* disable all watchpoints */
movq%r15,PCB_DR0(%r8)
movq%r14,PCB_DR1(%r8)
movq%r13,PCB_DR2(%r8)
movq%r12,PCB_DR3(%r8)
movq%r11,PCB_DR6(%r8)
movq%rax,PCB_DR7(%r8)
+   andq$0xfc00, %rax   /* disable all watchpoints */
movq%rax,%dr7
jmp done_store_dr
 
___
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: TCP over UDP

[Pieter de Goeje]

On Saturday 10 July 2010 14:05:29 Sergey Babkin wrote:
 Hi guys,
 
 I've got this idea, and I wonder if anyone has done it already,
 and if not then why. The idea is to put the TCP logic over UDP.
 
 I've done some googling and all I've found is some academical
 user-space implementations of TCP that actually try to interoperate
 with real TCP. What I'm thinking about is different. It's
 to use the TCP-derived logic as a portable library that would
 do the good flow control, retransmitting, delivery confirmations
 etc over UDP.
 
 Basically, every time you use UDP, you've got to reinvent your
 own retransmission and reliability protocol. And these protocols
 are typically no good at all, as the story with NFS switching
 from UDP to TCP and improving the performance shows. At the same
 time TCP provides a very good transport control logic, so why not
 just reuse this logic in a library to solve the UDP issues once
 and for all?
 
 Then of course, why not just use TCP? The problem of TCP is that
 it's expensive. It uses the kernel memory for its contexts.
 It also requires a file descriptor per each connection. The file
 descriptors are an expensive resource, and besides, even if
 the limit is raised, there is the issue with historic select()
 fd_set allocating only 1024 bits and nobody checking for the
 overflow. Even if your own code is carefully designed to avoid using
 select() at all and/or create large enough bitmasks, it could
 always happen to use some stupid library that doesn't do that
 and causes the interesting one-bit memory corruptions.
 
 Moving the connection logic to the user space makes the connections
 cheap. A hundred bytes or so per connection state is no big
 deal, you can easily create a million of these connections to
 the same process. All the state stays in the user-space pageable
 memory. Well, all of them sending data at the same time
 might not work so well, but caching a large number of currently
 inactive connections becomes cheap. Think of XMLRPC or SOAP
 or anything else over HTTP reusing the same TCP connection for
 multiple sequential requests. Now there is a painful balance
 of inactivity timeouts: make them too long and you
 overload the server, make them too short and the connections
 get dropped all the time. The cheap connections would allow
 to keep the much longer timeouts.
 
 Then there are other interesting possibilities arising from the easy
 access to the protocol state. The underlying datagramness can be
 exposed to the top level, and this immediately gives the transactional
 TCP. Or we could look at the state and find out if the data has
 been actually delivered to and confirmed by the other side.
 Or we can even drop the inactive connections at the server without
 notifying the client. Then if the client sends more requests on this
 connection, the server could semi-transparently re-establish it
 (OK, this would require an extension from TCP). Or we can do
 the better keep-alives, not the TCP's hour-long ones, but
 something within a few seconds (would not work too well with
 millions of connections, but it's a different use case where
 we want to detect the lost peer fast). Or having sub-channels,
 each with its own sequence number. If the data gets transferred
 over 100 parallel logical connections, few bytes at a time for
 each of them, combining the whole bunch into one datagram would
 be much more efficient tahn sending 100 datagrams. These are just
 the ideas off the bat, there's got to be more of these interesting
 usages.
 
 It all looks like such an obviously good idea, that I wonder,
 why didn't anyone else try it before? Or have they tried
 it and found that it's not such a good idea after all?
 
 -SB

TCP actually scales pretty well. All modern operating systems provide a way to 
do efficient select() operations, for example with FreeBSD's kqueue. Using a 
small bit of tuning one can effectively deal with 100k+ TCP connections on a 
single system. This mainly has to do with increasing the maximum number of 
filedescriptors and decreasing the maximum send/receive buffer sizes to 
conserve memory.

TCP provides very good throughput, and it achieves this using large send and 
receive buffers. Your userspace implementation will need to implement 
something similar. A few hundred bytes per connection is simply not enough.

If you want to deal with millions of clients, your protocol shall better not 
have any state at all. A good example of this is DNS.

I think that most applications can either use TCP directly with or without 
tuning or they have such specialized needs that a custom protocol is the only 
solution.

Regards,
Pieter de Goeje

___
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

tools/ directory is missing on recent install media.

[Julian H. Stacey]

Hi Hackers,
FreeBSD install media has lost the tools/ directory from recent CDs  DVDs:

Quoting
  http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-pre.html
... to resize your partitions and make space for FreeBSD. The
tools directory on the CDROM contains two free software
tools which can carry out this task, namely FIPS and PResizer
...
PartitionMagic and GParted are known to work on NTFS. GParted
is available on a number of Live CD Linux distributions,
such as SystemRescueCD.

There is no tools/ directory on recent FreeBSD CDROM disc1.iso  dvd1.iso
( or on memstick.img, no suprise as recent )
Maybe an older disc1.iso ran out of room,
 tools/ got dropped  forgotten, not replaced for next release ?
( Downloading all of
ftp://ftp2.de.freebsd.org/pub/FreeBSD/tools 
I see just 2 Meg, not much saving there unless desperate.
{ boot.bin bootinst.exe bsdboot ckdist.exe ckdist.man
dist extipl.exe fdimage.exe fips.doc fips.exe
fips.faq gunzip.exe gzip.exe ide_conf.exe md5.exe
osbs135.exe osbsbeta.exe pfdisk.exe presizer.doc
presizer.exe rawrite.exe restorrb.exe srcs }
Maybe author of dvd1.iso script didnt realise tools/
used to be on disc1.iso, but had got dropped [for space] ?
The DVD could easily take 2 meg (or is it copyright reasons FTP V. DVD?).

/pub/FreeBSD/releases/ 
My local copy has all of these  more:
amd64/ISO-IMAGES/7.2/7.2-RELEASE-amd64-disc1.iso
amd64/ISO-IMAGES/7.2/7.2-RELEASE-amd64-dvd1.iso
amd64/ISO-IMAGES/7.3/FreeBSD-7.3-RELEASE-amd64-disc1.iso
amd64/ISO-IMAGES/7.3/FreeBSD-7.3-RELEASE-amd64-dvd1.iso
amd64/ISO-IMAGES/8.0/8.0-RELEASE-amd64-bootonly.iso
amd64/ISO-IMAGES/8.0/8.0-RELEASE-amd64-disc1.iso
amd64/ISO-IMAGES/8.0/8.0-RELEASE-amd64-dvd1.iso
amd64/ISO-IMAGES/8.0/8.0-RELEASE-amd64-livefs.iso
amd64/ISO-IMAGES/8.1/FreeBSD-8.1-RC2-amd64-disc1.iso
amd64/ISO-IMAGES/8.1/FreeBSD-8.1-RC2-amd64-dvd1.iso
amd64/ISO-IMAGES/8.1/FreeBSD-8.1-RC2-amd64-memstick.img
i386/ISO-IMAGES/4.11/4.11-RELEASE-i386-disc1-gnome.iso
i386/ISO-IMAGES/6.3/6.3-RELEASE-i386-disc1.iso
i386/ISO-IMAGES/6.4/6.4-RELEASE-i386-disc1.iso
i386/ISO-IMAGES/6.4/6.4-RELEASE-i386-dvd1.iso
i386/ISO-IMAGES/7.2/7.2-RELEASE-i386-disc1.iso
i386/ISO-IMAGES/7.2/7.2-RELEASE-i386-dvd1.iso
i386/ISO-IMAGES/7.3/FreeBSD-7.3-RELEASE-i386-disc1.iso
i386/ISO-IMAGES/7.3/FreeBSD-7.3-RELEASE-i386-dvd1.iso
i386/ISO-IMAGES/8.0/8.0-RELEASE-i386-disc1.iso
i386/ISO-IMAGES/8.0/8.0-RELEASE-i386-dvd1.iso
i386/ISO-IMAGES/8.1/FreeBSD-8.1-RC2-i386-disc1.iso
i386/ISO-IMAGES/8.1/FreeBSD-8.1-RC2-i386-dvd1.iso
  ( Inconsistent naming also on
ftp://ftp.freebsd.org , with random prepend of .../FreeBSD-... )

I searched media above, tools/ was on 6.3-RELEASE-i386-disc1.iso but not on 6.4:
tools/ on ftp site contains:
bsdboot dist srcs srcs/EXTIPL srcs/EXTIPL/DEVELOP srcs/bteasy
srcs/fips srcs/fips/restorrb srcs/fips/source srcs/ide_conf
srcs/pfdisk srcs/rawrite

re@, 
I suggest consider regularising [scripts ?] to avoid
inconsistent prepend of .../FreeBSD-... to some image names.

dvd1.iso script author,
Please consider adding tools/
We might currently be losing some new people, tempted to
try BSD, who need to first download a Linux image with disk
partition shrinker (to run under Linux or MS, whatever),
who then may think:
 Why now dowload a BSD DVD too, Let's continue
 installing with this Linux DVD in the drive.

An idea for memstick.img later maybe:
Currently the UFS is on /dev/md0a , perhaps either we might
put tools ported to BSD on the UFS or tools that run from
MS, on an MSDOSFS on /dev/md0s2 ?

Partition Shrinker Tools:
A friend suggested 

http://jamesmcdonald.id.au/gnu-linux/linux-tools/shrink-your-windows-xp-ntfs-partition-to-half-size-and-install-linux-while-keeping-the-nt-bootloader

URLs/ reccomendations welcome for other public partition
shrinkers that run from install media (or MS, but no interest
in commercial licensed Partition Magic).

2 I'm downloading to try:

KNOPPIX_V6.2CD-2009-11-18-EN.isoloads of mirrors eg:
ftp.gwdg.de/pub/linux/knoppix/

http://gparted.sourceforge.net/

http://sourceforge.net/projects/gparted/files/gparted-live-testing/0.6.1-2/gparted-live-0.6.1-2.iso/download

Cheers,
Julian
--
Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
Mail plain text.  Not HTML, Not quoted-printable, Not Base64.
___

Re: kernel patch needed for wine?

[Sergei Hedgehog]

On Monday 12 July 2010 15:25:13 Tijl Coosemans wrote:
 Could you give the attached patch a try?
 
 cd /usr/src
 patch -p1  /path/to/patch-amd64-dr7
 make buildkernel installkernel

Thank you! This patch allowed me to login and enter the game world. I'll test 
the RealID feature later and submit results here. There is an another guy who 
is able to login after applying this patch too. Our system info:

FreeBSD 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE and wine 1.2-rc6
FreeBSD 8.0-RELEASE-p3 amd64 with wine 1.2-rc4

However, there is little problem: the game hangs at login attempt if I enter 
wrong password. I'll post logs here when I'll get more info.

Thank you for the patch.
___
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: tools/ directory is missing on recent install media.

[Ken Smith]

On Mon, 2010-07-12 at 17:38 +0200, Julian H. Stacey wrote:
 Hi Hackers,
 FreeBSD install media has lost the tools/ directory from recent CDs  DVDs:
 
 Quoting
   http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-pre.html
   ... to resize your partitions and make space for FreeBSD. The
   tools directory on the CDROM contains two free software
   tools which can carry out this task, namely FIPS and PResizer
   ...
   PartitionMagic and GParted are known to work on NTFS. GParted
   is available on a number of Live CD Linux distributions,
   such as SystemRescueCD.
 
 There is no tools/ directory on recent FreeBSD CDROM disc1.iso  dvd1.iso
 ( or on memstick.img, no suprise as recent )
 Maybe an older disc1.iso ran out of room,
  tools/ got dropped  forgotten, not replaced for next release ?

It wasn't a size issue that made me stop bothering to put the tools/
directory on, it was more an issue of the tools just not being current
any more and not having an idea of what to replace them with.  At
the point I stopped putting them on the media the world had gotten
to the point any tools that can't handle NTFS were useless.

 re@, 
   I suggest consider regularising [scripts ?] to avoid
   inconsistent prepend of .../FreeBSD-... to some image names.

FreeBSD- is consistently prepended to all the images that have been
generated past the date we decided to start prepending FreeBSD- to
the image names.  Images that were generated before we decided
to start prepending FreeBSD- to the image names consistently do
not have FreeBSD- prepended to them...  :-)

 dvd1.iso script author,
   Please consider adding tools/
   We might currently be losing some new people, tempted to
   try BSD, who need to first download a Linux image with disk
   partition shrinker (to run under Linux or MS, whatever),
   who then may think:
Why now dowload a BSD DVD too, Let's continue
installing with this Linux DVD in the drive.

It won't happen in time for 8.1 but I'll try to invest some time
in digging up reasonable replacements for the tools that had been
there.  Thanks for passing on your friend's suggestion.

-- 
Ken Smith
- From there to here, from here to  |   kensm...@buffalo.edu
  there, funny things are everywhere.   |
  - Theodore Geisel |



signature.asc
Description: This is a digitally signed message part

Re: [PATCH] Fix typos in bsd.port.mk and minor logic improvements

[Doug Barton]

On 07/09/10 08:11, Garrett Cooper wrote:
 -# UNAUTHORISED CHANGES WILL BE UNCONDITIONALLY REVERTED!
 +# UNAUTHORIZED CHANGES WILL BE UNCONDITIONALLY REVERTED!

Couple of comments. The above is not a typo, that's the British
spelling. We generally don't change those. (Arguably it adds character
to the project.) :)

The other is more of a question, I'm not sure what the point of these
changes is: ${var:-} The :- parameter substitution kicks in if var is
unset or null, but you're not substituting it with anything.


Doug

-- 

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

___
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: TCP over UDP

[Bruce Cran]

On Sat, 10 Jul 2010 08:05:29 -0400
Sergey Babkin bab...@verizon.net wrote:

 Basically, every time you use UDP, you've got to reinvent your
 own retransmission and reliability protocol. And these protocols
 are typically no good at all, as the story with NFS switching
 from UDP to TCP and improving the performance shows. At the same
 time TCP provides a very good transport control logic, so why not
 just reuse this logic in a library to solve the UDP issues once
 and for all?

Have you looked at SCTP? It may provide the features you've looking
for:
http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol#Motivations

-- 
Bruce Cran
___
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: kernel patch needed for wine?

[Sam Fourman Jr.]

On Mon, Jul 12, 2010 at 7:25 AM, Tijl Coosemans t...@coosemans.org wrote:
 On Wednesday 30 June 2010 01:54:11 Sam Fourman Jr. wrote:
 Last Tuesday blizzard release World of Warcraft 3.3.5, and with this
 patch World of warcraft stopped working in FreeBSD 8.1 amd64, it
 crashes right after login.

 I have been playing World of Warcraft on FreeBSD amd64 since December
 of 2009 using the beta Nvidia 64bit drivers and this wine how-to

 http://wiki.freebsd.org/Wine#head-6963d527c173e57b1567e881305b544d33435b6d

 I can verify that on PCBSD 8.1 RC1 32bit World of warcraft works post
 3.3.5 so far as I can tell it is only broken on amd64.

 Could you give the attached patch a try?

 cd /usr/src
 patch -p1  /path/to/patch-amd64-dr7
 make buildkernel installkernel


I can confirm that this fixes wow post 3.3.5
on FreeBSD amd64 using cvs tag RELENG_8

it also works on PC-BSD 8.1 amd64 with the applied patch
-- 

Sam Fourman Jr.
Fourman Networks
http://www.fourmannetworks.com
___
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: kernel patch needed for wine?

[Sergey Nikolenko]

On 12.07.2010 18:25, Tijl Coosemans wrote:

Last Tuesday blizzard release World of Warcraft 3.3.5, and with this
patch World of warcraft stopped working in FreeBSD 8.1 amd64, it
crashes right after login.

I have been playing World of Warcraft on FreeBSD amd64 since December
of 2009 using the beta Nvidia 64bit drivers and this wine how-to

http://wiki.freebsd.org/Wine#head-6963d527c173e57b1567e881305b544d33435b6d

I can verify that on PCBSD 8.1 RC1 32bit World of warcraft works post
3.3.5 so far as I can tell it is only broken on amd64.


Could you give the attached patch a try?

cd /usr/src
patch -p1  /path/to/patch-amd64-dr7
make buildkernel installkernel


Just tried, it works.
Gamers will be happy I suppose. :)
___
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

sysctl question

[Andreas Tobler]

Dear all,

I have an issue here, I do read a temperature sensor and I got a value 
back, in integer. This value is 'encoded', it contains the integer and 
the fractional part of the temperature I read.


This is inside a kernel module. I offer a sysctl interface to read this 
value. Currently the access is done with sysctl_handle_int.


In my userland application I can print this value with the following macro:

FIX32TOPRINT(f) ((f)  16),f)  0x) * 1000)  16)

But now I wonder how can I teach the sysctl to print my tempreature the 
same way as my userland app does.


Right now it looks this way:
dev.sm.1.sensor.cpu_b_ad7417_amb.temp: 2736128

If I feed this 2736128 into the macro above I get this:

41.750 this is what I expect.

Is this even possible?

TIA for any pointer.

Andreas
___
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: elf obj load: skip zero-sized sections early

[Andriy Gapon]

on 12/07/2010 00:38 Andriy Gapon said the following:
 on 12/07/2010 00:15 Jeff Roberson said the following:
[snip]
 I appreciate your analysis but I don't understand the motivation for
 changing working code.
 
 Primary reason is that the working code produces zero-sized 
 unused/unnecessary

I think that my use of quotes was inappropriate in this sentence.
The code is indeed working, just with that certain side-effect.

 pcpu_set sections.  See the subject line.  As to why I care about those 
 sections
 - please see the start of this thread.

-- 
Andriy Gapon
___
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

inet_* functions in kernel?

[Bartosz Marcin Kojak]

Hi.

Currently I'm writing a kernel module using MAC Framework to control  
binding to local IP addresses (kind of mac_portacl variation) and I need  
some advice.


I want to be able to write rules for module through sysctl (rule will  
contain IP addresses in human-readable format, e.g.  
uid:1002:192.168.2.3) and I'm wondering how to translate addresses to  
network byte order without inet_* functions.  Well, they look like they're  
available to use in kernel (using netinet/in.h) but it's no able to  
compile module with inet_* functions using typical Makefile (this one with  
.include bsd.kmod.mk line) - it just produces warnings, and all  
warnings are treated as errors in this case.


So, possible solutions are: just add custom CFLAGS without -Werror to  
Makefile (but it's quite ugly though) or write an userspace application  
that will write an addresses in NBO to sysctl (but now sysctl won't be  
easy to read and modify by hand).


What do you think?

Thanks in advance for any useful hints.

--
SIGSTOP
___
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: inet_* functions in kernel?

[Boris Kochergin]

Bartosz Marcin Kojak wrote:


Hi.

Currently I'm writing a kernel module using MAC Framework to control 
binding to local IP addresses (kind of mac_portacl variation) and I 
need some advice.


I want to be able to write rules for module through sysctl (rule will 
contain IP addresses in human-readable format, e.g. 
uid:1002:192.168.2.3) and I'm wondering how to translate addresses 
to network byte order without inet_* functions.  Well, they look like 
they're available to use in kernel (using netinet/in.h) but it's no 
able to compile module with inet_* functions using typical Makefile 
(this one with .include bsd.kmod.mk line) - it just produces 
warnings, and all warnings are treated as errors in this case.


So, possible solutions are: just add custom CFLAGS without -Werror 
to Makefile (but it's quite ugly though) or write an userspace 
application that will write an addresses in NBO to sysctl (but now 
sysctl won't be easy to read and modify by hand).


What do you think?

Thanks in advance for any useful hints.


Check out the byteorder(9) man page.

-Boris
___
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: kernel patch needed for wine?

[Oliver Pinter]

CC pipacs and Hunger  ;)

On 7/1/10, Uffe Jakobsen u...@uffe.org wrote:

 Garrett writes:
 Also, is there perhaps a sideeffect dealing with the size of a char on
 FreeBSD vs Linux?

 That's a pretty badass way to load assembler instructions on the stack
 :).


 I may be totally wrong here - but could it be NX/XD/XN protection ?

 /Uffe


 ___
 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: TCP over UDP

[Sergey Babkin]

Dirk-Willem van Gulik wrote:
 
 On 10 Jul 2010, at 13:05, Sergey Babkin wrote:
 
  I've got this idea, and I wonder if anyone has done it already,
  and if not then why. The idea is to put the TCP logic over UDP.
 
 Have you looked at T/TCP [1,2,3] ?
 
 Dw
 
 1: http://www.manpages.info/freebsd/ttcp.4.html
 2: http://en.wikipedia.org/wiki/T/TCP
 3: 
 http://people.freebsd.org/~andre/Optimizing%20the%20FreeBSD%20IP%20and%20TCP%20Stack%20-%20Presentation.pdf

It's been a sort of a remote inspiration :-) A major problem
with it (besides the security stuff listed on Wiki) is that
it's implementation is in-kernel, and as such can be used
directly only when the OS has the implementation. There is no 
way to write a portable application with it.

Other than that, I'm proposing an opposite approach: why bother
about reducing the cost of the initial connection, if we can
instead just open the connection once and then keep it open
for a very long time at a low cost?

-SB
___
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: Missing files device_if.h and bus_if.h

[M. Warner Losh]

Not quite.  Make creates them...

Matthew Jacob m...@feral.com writes:
: config(8) creates them I believe
:
:  line 523 of bus.h
: 
:  tries to include the following files:
: 
:  #include device_if.h
:  #include bus_if.h
: 
:  however, I don't see them any where in my source tree.  Are these
:  missing or am I suppose to create them or are they built as part of
:  the build process and if the latter then why didn't I get a copy when
:  I built a custom kernel?
: 
:  Where do I get these files?  Could someone please clue me in here?
: 
:  And since I am asking questions here, I see BUS_READ_IVAR used a
:  couple of places but can't find it's definition.  Where is it defined?
: 
:  Thanks
:  Christopher
:  ___
:  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
: 
___
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: TCP over UDP

[Sergey Babkin]

Pieter de Goeje wrote:
 
 On Saturday 10 July 2010 14:05:29 Sergey Babkin wrote:
  Hi guys,
 
  I've got this idea, and I wonder if anyone has done it already,
  and if not then why. The idea is to put the TCP logic over UDP.
 
  I've done some googling and all I've found is some academical
  user-space implementations of TCP that actually try to interoperate
  with real TCP. What I'm thinking about is different. It's
  to use the TCP-derived logic as a portable library that would
  do the good flow control, retransmitting, delivery confirmations
  etc over UDP.
 
 TCP actually scales pretty well. All modern operating systems provide a way to
 do efficient select() operations, for example with FreeBSD's kqueue. Using a
 small bit of tuning one can effectively deal with 100k+ TCP connections on a

Not in a single process though.

 single system. This mainly has to do with increasing the maximum number of
 filedescriptors and decreasing the maximum send/receive buffer sizes to
 conserve memory.

Only in theory. My practical experience goes like this: How 
many parallel clients can our multithreaded server handle?
Why, it should be easy to scale to almost anywhere, just
bump the limit on the file descriptors. Bumped, tried. It
crashes soon after 1000 connections. Why? A week later,
the investigation has shown that we use PAM, and a PAM library
for network authentication opens its own socket, and calls
select() on it. It uses the standard fd_set, so when the socket
happens to be above 1024, it corrupts the stack. So the only
way to get a large number of file descriptors is in a very
controlled environment, making sure not to use any 3rd-party
or system libraries that might ever want to call select().
 
 TCP provides very good throughput, and it achieves this using large send and
 receive buffers. Your userspace implementation will need to implement
 something similar. A few hundred bytes per connection is simply not enough.

A hundred or less bytes just for the state, for a connection
that doesn't transfer anything at the moment. HTTP 1.1 and
SOAP services on top of it do this: open a connection, and then
after the first request keep it open, in case if they would want
to send more requests. The minimum state would be pretty much a pair
of addresses and sequence numbers, plus whatever tree or hash
table overhead used to organize them.
 
 If you want to deal with millions of clients, your protocol shall better not
 have any state at all. A good example of this is DNS.

DNS is actually a very bad example IMO. A very fragile protocol
that trips over itself all the time. On the contrary, it's another 
case that should be able to benefit a lot from TCP-over-UDP.
 
-SB
___
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

an alternative to powerpoint

[Luigi Rizzo]

Maybe you all love powerpoint for presentations, but sometimes
one just needs to put together a few slides, perhaps a few bullets
or images grabbed around the net, so i was wondering how hard
would it be to do something that accepts a plain text file
as input (without a ton of formatting) and lets you do a decent
slide show, and supports editing the slides on the fly within
the browser.

Well, it's not too hard:

http://info.iet.unipi.it/~luigi/sttp/

just 400 lines of javascript and 100 lines of css, plus
your human-readable text.

Have fun, it would be great if you could report how it works
on fancy devices (iphone, ipad, androids...) as my testing
platforms are limited to Firefox, IE and chrome (which unfortunately
cannot save the edited file)

cheers
luigi
___
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: TCP over UDP

[Sergey Babkin]

Bruce Cran wrote:
 
 On Sat, 10 Jul 2010 08:05:29 -0400
 Sergey Babkin bab...@verizon.net wrote:
 
  Basically, every time you use UDP, you've got to reinvent your
  own retransmission and reliability protocol. And these protocols
  are typically no good at all, as the story with NFS switching
  from UDP to TCP and improving the performance shows. At the same
  time TCP provides a very good transport control logic, so why not
  just reuse this logic in a library to solve the UDP issues once
  and for all?
 
 Have you looked at SCTP? It may provide the features you've looking
 for:
 http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol#Motivations

Thanks, it does look like it!

-SB
___
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: an alternative to powerpoint

[Bakul Shah]

On Tue, 13 Jul 2010 06:15:14 +0200 Luigi Rizzo ri...@iet.unipi.it  wrote:
 Maybe you all love powerpoint for presentations, but sometimes
 one just needs to put together a few slides, perhaps a few bullets
 or images grabbed around the net, so i was wondering how hard
 would it be to do something that accepts a plain text file
 as input (without a ton of formatting) and lets you do a decent
 slide show, and supports editing the slides on the fly within
 the browser.
 
 Well, it's not too hard:
 
   http://info.iet.unipi.it/~luigi/sttp/
 
 just 400 lines of javascript and 100 lines of css, plus
 your human-readable text.
 
 Have fun, it would be great if you could report how it works
 on fancy devices (iphone, ipad, androids...) as my testing
 platforms are limited to Firefox, IE and chrome (which unfortunately
 cannot save the edited file)

Seems to work fine in Safari  Opera.

Your note inspired me to search the 'Net!  Since I prefer
\latex{goop} to htmlgoop/html I went looking for a latex
class and found 'Prosper'.  Looks like it can produce some
really nice slides! See the examples here:

http://amath.colorado.edu/documentation/LaTeX/prosper/

And here is a tutorial:

http://www.math.umbc.edu/~rouben/prosper/

And of course, it is already in /usr/ports/textproc/prosper!
I will have to give it a try as I was getting tired of
fiddling around in Keynote (and I don't like powerpoint).

[Hope you don't mind my mentioning Prosper!]
___
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