Darryl Okahata <[EMAIL PROTECTED]> writes:
> Well, I was going to take Ville-Pertti Keinonen's ([EMAIL PROTECTED])
> ESS2 mixer code and turn it into an LKM, which I'd then try to add sound
> output using the Linux code. However, I'm not familiar with how one
> accesses interrupts and DMA
Edwin Kremer <[EMAIL PROTECTED]> writes:
>" OpenSSH is based on my version from back in 1995 or 1996. The OpenSSH
>" folks have fixed many of the (security) bugs in that version, but not
>" all of them when I last checked. Some of the problems in SSH1 are
>" very fundamental.
>
Mark Murray <[EMAIL PROTECTED]> writes:
> Me three. Time for us all to read the SSH rfc's, methinks...
The last time I looked, the ssh1 RFC wasn't up-to-date with the actual
protocol (version 1.5) implemented by ssh-1.2.x.
It is also quite likely that the protocol is defined only by how the
im
> > Note that double-alignment vs. word-alignment can really have >30%
> > performance impact, at least on an Athlon and one meaningless floating
> > point microbenchmark (operations on small, fixed-sized
> > matrices...maybe it isn't even *that* meaningless).
>
> I verified that the default ali
> > > Maybe alignment can even be done in the kernel...
> >
> > It gets messy, it has to be done before putting the env and argv
> > pointers in place...
>
> Alignment also applies to calling signal handlers...
Which is easier because sigframe has a constant size and you know what
the relation
> AFAICT, it's enough to just align the stack before doing anything else.
> In this case it means aligning the stack somewhere before
> (exit(main(...)). gcc maintains proper alignment on an aligned stack.
I wouldn't rely on that, gcc is free to assume that it can address
local variables relativ
Ok, I've checked, and in -current, userland stack boundary alignment
is useless because the stack pointer is initially only aligned on a
word-boundary.
I've also verified that the correct alignment is indeed expected to
apply to frame pointers, i.e. stored frame pointers are at aligned
stack slo
Bruce Evans <[EMAIL PROTECTED]> writes:
> If the caller has passed a double, then the stack alignment can be determined
> at compile time and the current subl-type adjustment can be used.
Doubles are not aligned when passed as parameters and passing a double
doesn't guarantee that there are loc
> The stack must be aligned before the return address is pushed:
>
> The following C fragment
> f(1);
> f(2);
>
> Translates to
>
> addl $-12,%esp
> pushl $1
> call f
> addl $16,%esp
> addl $-12,%esp
> pushl $2
> call f
>
> It would be better for GCC to force alignment only within those
> procedures that need it rather then force all procedures to guarentee
> alignment. Then we could have the best of both worlds.
Determining whether it is necessary is non-trivial, you would have to
go through all lo
> > Anyhow, I'll repeat it here - stack alignment does *not* break
> > link-compatibility. It does not change calling conventions, it just
> > adds padding after the args to ensure that local variables can be
> > predictably aligned.
> So, how does aligning stackframes affect the inherently sta
> What about commercial and/or third party KLDs? They fail to work if they
> don't also set -preferred-stack-boundry=2, right?
Oops, I accidentally replied to this privately.
Anyhow, I'll repeat it here - stack alignment does *not* break
link-compatibility. It does not change calling conventio
Julian Elischer <[EMAIL PROTECTED]> writes:
> When did this come in? (I have been seeing it for a while but..
> I thought this was to save space on the bootblocks, not the entire
> kernel?)
> Do we really want shorts being pushed onto the stack as shorts?
> (This is what this implies)
No, the
Stephen Roome <[EMAIL PROTECTED]> writes:
> As the title says, is anyone working on support for Athlons, and when can we
> expect it to arrive back in -stable ?
Athlons don't need any special support, they are fully compatible with
Intel's latest processors.
> (I can't find anything in the lat
> It wasn't a problem in -current due to a different way that things
> were done there.
What things, exactly? I haven't noticed any differences in
vfs_cache.c or vfs_subr.c that should affect the caching behavior, so
it must just be that the system survives a large amount of wired down
memory b
Warner Losh <[EMAIL PROTECTED]> writes:
> In message <[EMAIL PROTECTED]> Kenneth
>Culver writes:
> : Check this out, if anyone is intrested.
> :
> : I found this on packetstorm.securify.com tonight. Any ideas??
> Mycroft sent this out after we had fixed this before the 3.3R
> release. At lea
> >If you want to include the other attack I mentioned (I just tried it,
> >got up to > 16 vnodes), then you have to exclude vnodes that are
> >only live because of v_cache_src entries from the count.
>
> It should probably only count vnodes in "actual" use.
There's no counter for that curr
> I have been mulling over this issue for some time. My current thinking
> is that pending some more well thought out mechanism, the right thing
> to do here is to detect the DOS and react to that, not to handicap
> the caching in general.
>
> The easiest way to detect this DOS is probably to k
Replying to myself...
> Looking at the code, it would seem that the number of directories is
> what's causing problems (one is created for each link). The directory
> vnodes can't be thrown out because a name cache entry exists in each
> one. All of the name cache entries point to the same vno
Kenneth Culver <[EMAIL PROTECTED]> writes:
> I ran this on a machine running FreeBSD 3.2-RELEASE with 256MB of RAM,
> and it chugged along to about `02/03000' (meaning it created 3 files
> and about 63000 or so links), consuming a whopping 34MB of wired
> kernel memory (according to `top'), befo
"Daniel C. Sobral" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> >
> > But specifying something too high (-O99) doesn't hurt - I'm using -O6 for
> > gcc 2.95.1 (which, by the way, compiles almost everything in 3.3-RELEASE
> > and 4.0-CURRENT, the only thing still troubling me with it
Oliver Fromme <[EMAIL PROTECTED]> writes:
> The gcc optimizer is traditionally buggy. I wouldn't trust a
> system compiled with anything more than -O (especially on
> production servers). The higher optimization levels don't
> provide much of a speed improvement anyway, sometimes they make
> t
Luigi Rizzo <[EMAIL PROTECTED]> writes:
> Is there any way to guarantee (more or less strictly, see below)
> that when i issue a read() on a file (a real file coming from a
> UFS i mean) such read will not block because data from the disk is
> not in memory yet, yet avoid that i end up in a busy
Poul-Henning Kamp <[EMAIL PROTECTED]> writes:
> The third difference is that we only use jurys in murder cases,
> we fully realize the ability of a showman-laywer to sway a jury,
> therefore we don't use them, unless the issue is the gravest
> crime we know off.
That doesn't seem quite valid, i
Christopher Sedore <[EMAIL PROTECTED]> writes:
> You can see my report of issues in kern/12053. I somehow managed to
> include a mangled and outdated version of the patch with that report, so
> that patch shouldn't be integrated. An updated patch is available at
> http://tfeed.maxwell.syr.edu/
Alan Cox <[EMAIL PROTECTED]> writes:
> Almost all of these vm_map_entry's started out as a single entry that got
> fragmented as mprotects were performed by the garbage collector.
> Instead of maintaining the page protections as part of the vm_map_entry,
> you could separate them into a smaller,
Alan Cox <[EMAIL PROTECTED]> writes:
> P.S. As an aside, just once, everyone should look at the /proc/"pid"/map
> of a running cvsup. Each line you see is a vm_map_entry. (What you
> see is a result of Modula-3's garbage collector.) Roughly speaking,
Modula-3 really appears to be doing some
Alex Zepeda <[EMAIL PROTECTED]> writes:
> > > Why is rc.conf readable by world?!
> >
> > Why not?
>
> What reason would the rest of the "world" have to read rc.conf? It could
> only create a possible security risk.
Unix systems are typically designed the other way around - don't
read-protect
Ustimenko Semen writes:
> Is this a good tactic to write working VOP_BMAP and
> VOP_STRATEGY handlers, and implement VOP_READ and VOP_WRITE
> via bread and bwrite of own vnodes?
Considering that that's how the primary filesystem layers (ufs/ffs) do
it, it should be fair to assume that it's at l
This small patch doesn't fix any major bugs (mostly the XXX in the
comment before cache_purge in kern/vfs_cache.c), but should be a step
towards allowing a dynamically sized vnode cache to be used. This is
done by eliminating the reliance on a vnode pointer/v_id pair as a
unique identification fo
Matthew Dillon writes:
> To be blunt, the 'total VM' used by a system can run into the gigabytes
> while the actual real memory + swap allocation is 1/10 of that... or
Add another 1000% for stack autoextension... ;--)
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscr
Warner Losh writes:
> In message <199904102057.paa27...@home.dragondata.com> Kevin Day writes:
> : i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid
> : 1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's
> : 40 processes get 50% cpu shared between
> If it's a redirected output file you simply make it O_APPEND, at which
> point the seek offset in the descriptor becomes irrelevant.
As others have pointed out, O_APPEND is much newer than the
offset-sharing behavior.
It also doesn't fix things for inputs. Of course with buffering, it
Matthew Dillon writes:
> UNIX has been broken this way from day 1. It was a major design mistake.
> The only way to get your own descriptor seek offset is to open() the
> file again.
It's not necessarily breakage. Not having any mechanism other than
open to get your own seek offse
"John S. Dyson" writes:
> I just wanted to "chime in" and say that the new patches are based
> on a really good concept, and is much cleaner than the previous
> method. Also, many RISC architectures can utilize this
> method due to the availability of lots of general registers.
> (One could go
Sheldon Hearn writes:
> I'm not sure I understand what real-world frustrations people are having
> here. Is this thread the product of reactionary criticism, or are there
> real examples of situations in which there are serious disadvantages to
> the way Soren has things working?
So far, you se
Jeroen Ruigrok/Asmodai <[EMAIL PROTECTED]> writes:
> Looking at /usr/src/sys/i386/i386/identcpu.c I see that the 0x580 is:
>
> case 0x580:
> strcat(cpu_model, "K6-2");
> break;
>
> Which gets copied into:
>
> printf("CPU: ");
> strncpy(cpu_model, i386_cpus[cpu].cpu_name, sizeof cp
37 matches
Mail list logo
