It seems Vallo Kallaste wrote:
> On Tue, Apr 13, 1999 at 10:58:45PM +0200, Soren Schmidt
> wrote:
>
> > Yep that is exactly what it means, however the driver in -current
> > doesn't take advantage of it yet, but its on my TODO list.
> > The reason why I put in this verbosity, is so I can get a h
John Polstra wrote:
>
> If we had kernel threads and Modula-3 supported them, this wouldn't be
> a problem. But those are two very big ifs. :-(
Alternatively, if you could use aio.h in Module-3, this wouldn't be
a problem either.
--
Daniel C. Sobral(8-DCS)
d...@newsguy.c
>
>
> On Tue, 13 Apr 1999 18:34:25 Ilya Naumov wrote:
> > Hello Gianmarco,
> >
> > Thursday, April 08, 1999, 7:49:52 AM, you wrote:
> >
> > GG> "ftp" on 4.0-very-current (post egcs make world) randomly hangs during
> > GG> sessions...
> > GG> I never succeded in finishing a session lately.
> > GG>
John Polstra wrote:
> > That statement made me think that Modula-3 had it's own threading
> > support because our native threads using non-blocking file I/O.
>
> For disk I/O? Are you sure? If so then it must use the aio/lio calls
> or something similar. Disk I/O calls _always_ block, even if y
Matthew D. Fuller wrote:
>> But six hours and sixteen minutes? That's awfully slow. You must
>> have had a really bad link that day. I'd try a few different mirror
>> sites if I were you.
>
> Nono, 6 minutes and 16 seconds :P
> *lovin it*
Ohhh! Heh, you had me worried for a minute there
Daniel Eischen wrote:
> John Polstra wrote:
>
>> My hunch is that it's not a fairness issue. It's just the fact that
>> when you block in disk I/O, the whole process (all threads) blocks.
>
> That statement made me think that Modula-3 had it's own threading
> support because our native threads u
On Tue, Apr 13, 1999 at 03:41:46PM -0700, a little birdie told me
that John Polstra remarked
> Matthew D. Fuller wrote:
>
> > After about 4 days without cvsup'ing (including lots of fun gcc/egcs)
> > updates it took 6:16 to update my CVS repo including:
>
> When CVSup is fetching entirely new fil
%On Tue, Apr 13, 1999 at 03:16:01PM -0700, Kurt D. Zeilenga wrote:
%> To facilate auto detection of the local threading environment,
%> it would be nice if the -?thread options set all the necessary
%> compiler/linker flags. It is a common practace for such
%> options to specify both compilation a
John Polstra wrote:
> > Does Modula-3 use libc_r, or does it have it's own user thread support?
>
> It has its own. It can be ported to use native threads, but it's a
> non-negligible amount of work. It hardly seems worth it for the GUI
> alone.
No argmuent here. It's just that if it was using
On Tue, Apr 13, 1999 at 03:16:01PM -0700, Kurt D. Zeilenga wrote:
> To facilate auto detection of the local threading environment,
> it would be nice if the -?thread options set all the necessary
> compiler/linker flags. It is a common practace for such
> options to specify both compilation and li
Poul-Henning Kamp once wrote:
> >> If you unset the datasize limit and the program does not exceed
> >> the maximum system-supported datasize limit, malloc() should
> >> not return NULL even if the system is out of swap.
> >Can you explain why? Our malloc(3) is a little fuzzy as to th
Matthew D. Fuller wrote:
> After about 4 days without cvsup'ing (including lots of fun gcc/egcs)
> updates it took 6:16 to update my CVS repo including:
When CVSup is fetching entirely new files, it can't do anything much
smarter than compress them. It can't avoid moving the bits from point
A to
Daniel Eischen wrote:
> Does Modula-3 use libc_r, or does it have it's own user thread support?
It has its own. It can be ported to use native threads, but it's a
non-negligible amount of work. It hardly seems worth it for the GUI
alone.
> The recent set of commits to libc_r changed the thread
On Tue, 13 Apr 1999 18:34:25 Ilya Naumov wrote:
> Hello Gianmarco,
>
> Thursday, April 08, 1999, 7:49:52 AM, you wrote:
>
> GG> "ftp" on 4.0-very-current (post egcs make world) randomly hangs during
> GG> sessions...
> GG> I never succeded in finishing a session lately.
> GG> To transfer some f
To facilate auto detection of the local threading environment,
it would be nice if the -?thread options set all the necessary
compiler/linker flags. It is a common practace for such
options to specify both compilation and link options.
I suggest the EGCS specs be adjusted to:
-pthread => -D_THRE
On Tue, Apr 13, 1999 at 10:58:45PM +0200, Soren Schmidt wrote:
> Yep that is exactly what it means, however the driver in -current
> doesn't take advantage of it yet, but its on my TODO list.
> The reason why I put in this verbosity, is so I can get a hint to
> which drives support it, and it see
On Tue, Apr 13, 1999 at 08:29:30AM -0700, a little birdie told me
that John Polstra remarked
> Matthew D. Fuller wrote:
> >
> > As a data point, CVSup runs nicely, but if I iconify it and deiconify it,
> > it takes about forEVER (maybe 10, 15 seconds on a PPro 180) to redisplay
> > itself complete
On Wed, 14 Apr 1999, UCHIYAMA Yasushi wrote:
> NetBSD drivers already bus-specific frontend code was separated from
> bus-independent(backend) code. So easy to adapt another buses.
> I've tested its separation for FreeBSD's ep code, but it was already
> done by NetBSD. ed case, I determined
John Polstra wrote:
> Correct. I have not tried to analyze where the delays come from.
> But I do have a guess.
>
> CVSup uses user-level threads. If a thread gets blocked waiting for
> network I/O, the thread scheduler can run a different thread while it
> is waiting. A subsequent call to sele
| it seems to duplicate a lot of code already in FreeBSD, by just replacing
| it with the equivalent code from NetBSD.
|
| (or rather, jsut adding the NetBSD code and not using the FreeBSD
| version. This is acceptable in a test scenario).
ep at isa/pcmcia/cardbus ... I fully rewrote code t
Thomas Schuerger wrote:
> cvsup is mostly based on disk (and network) I/O, so there shouldn't
> be a problem with properly updating the GUI. Someone said it is
> done in a separate process, so I still wonder why the GUI is updated
> so slowly on my PII/450.
Not a separate process -- a separate th
On Tue, 13 Apr 1999, Thomas Schuerger wrote:
> > > Here's the bottom line from my point of view. CVSup is slow to update
> > > the GUI because it is busy doing more important things, i.e., updating
> > > your files as quickly as it can. I agree that it can be annoying. But
> > > would you really w
Mikhail Teterin wrote:
> However, the CPU is not 100% busy, and the cvsup is still slow to
> update sometimes... Updating it does not need anything but the CPU,
> does it (on the local display)?
Correct. I have not tried to analyze where the delays come from.
But I do have a guess.
CVSup uses u
It seems Vallo Kallaste wrote:
> Hello !
>
> Recently installed March 12 -current snapshot and compiled kernel
> with new IDE subsystem. I see interesting lines in dmesg:
> ad1: 16 secs/int, 31 depth queue, DMA mode
> Does it mean that new ATA disks can queue up commands (something
> similar
In message <199904121505.laa70...@misha.cisco.com>, Mikhail Teterin writes:
>Matthew Dillon once wrote:
>
>> If you unset the datasize limit and the program does not exceed
>> the maximum system-supported datasize limit, malloc() should not
>> return NULL even if the system is out of s
Hello !
Recently installed March 12 -current snapshot and compiled kernel
with new IDE subsystem. I see interesting lines in dmesg:
npx0: INT 16 interface
ata0: master: settting up UDMA2 mode on PIIX4 chip OK
ad0: ATA-4 disk at ata0 as master
ad0: 3079MB (6306048 sectors), 6256 cyls, 16 heads,
So I've been lookin gat this patch set..
it seems to duplicate a lot of code already in FreeBSD, by just replacing
it with the equivalent code from NetBSD.
(or rather, jsut adding the NetBSD code and not using the FreeBSD
version. This is acceptable in a test scenario). What is not so clear is
wha
"Rick Whitesel" wrote:
> Hi:
> I should have been more clear. BSD driver interoperability is a seperate
> issue from Linux application interoperability but I think both are
> important.
I don't want to get hopes up prematurely, but we think we might be able to
emulate enough of the newconfig-s
> Hi:
> I should have been more clear. BSD driver interoperability is a seperate
> issue from Linux application interoperability but I think both are
> important.
For an example of Linux/*BSD driver interoperability and the grief and
difficulties therein, you might want to look at the Qlogic
> > Here's the bottom line from my point of view. CVSup is slow to update
> > the GUI because it is busy doing more important things, i.e., updating
> > your files as quickly as it can. I agree that it can be annoying. But
> > would you really want me to slow down file updates just so the GUI
> > c
Hi:
I should have been more clear. BSD driver interoperability is a seperate
issue from Linux application interoperability but I think both are
important.
Rick Whitesel
Scientist
NBase-Xyplex
rwhite...@nbase-xyplex.com
"They that can give up essential liberty to obtain a little temporary
saf
John Polstra once wrote:
> > As a data point, CVSup runs nicely, but if I iconify it and
> > deiconify it, it takes about forEVER (maybe 10, 15 seconds on a PPro
> > 180) to redisplay itself completely.
> Yes, that's when the problem is most obvious.
>
> Here's the bottom line from my point of
Since some interested parties don't have CVSup access to freefall, I
have made the "newbus" collection that Peter announced available on
one public mirror site: cvsup2.freebsd.org.
Use collection "newbus", release=cvs. Don't forget to specify a
dedicated directory for the "prefix". This collecti
On Tue, 13 Apr 1999, Rick Whitesel wrote:
> Hi:
> I just wanted to say that I see this as very important work. BSD and
> Linux interoperability is the best way to insure the BSDs survive (and maybe
> better) the Linux mania.
I think the work is important too but it won't improve interoperabil
John Polstra wrote:
>Matthew D. Fuller wrote:
>>
>> As a data point, CVSup runs nicely, but if I iconify it and deiconify it,
>> it takes about forEVER (maybe 10, 15 seconds on a PPro 180) to redisplay
>> itself completely.
>
>Yes, that's when the problem is most obvious.
>
>Here's the bottom line
Hello Gianmarco,
Thursday, April 08, 1999, 7:49:52 AM, you wrote:
GG> "ftp" on 4.0-very-current (post egcs make world) randomly hangs during
GG> sessions...
GG> I never succeded in finishing a session lately.
GG> To transfer some files from my home to my isp server I had to do an "ftp"
GG> from t
Wow, this is getting deep.
Mikhail, give it a break. You _cannot_ prevent a determined attacker from
cauing a system a lot of heartache. For every subsystem that you harden,
you introduce new weaknesses and more performance hits which can themselves
be used as vulnerabilities. I'd bet my reputa
Matthew D. Fuller wrote:
>
> As a data point, CVSup runs nicely, but if I iconify it and deiconify it,
> it takes about forEVER (maybe 10, 15 seconds on a PPro 180) to redisplay
> itself completely.
Yes, that's when the problem is most obvious.
Here's the bottom line from my point of view. CVSu
In message <199904131325.jaa08...@kot.ne.mediaone.net>, Mikhail Teterin writes:
>Poul-Henning Kamp once stated:
>
>=>Why don't we admit this possibility exists (as well as many others,
>=>perhaps) for a local user to cause a DoS and may be someday someone
>=>will address it?
>
>=Because we have (co
Poul-Henning Kamp once stated:
=>Why don't we admit this possibility exists (as well as many others,
=>perhaps) for a local user to cause a DoS and may be someday someone
=>will address it?
=Because we have (counts for a moment, but as he flips to the third
=page of notes sighs deeply and gives u
On Sat, 10 Apr 1999, Kevin Day wrote:
> On the shell servers I run, we've got 200-300 users running tasks.
> Occasionally, through intent or misconfiguration, a user either forkbombs,
> or gets a large number of processes running sucking lots of cpu.
>
> I'd like to see an option that makes all t
In message <199904131256.iaa08...@kot.ne.mediaone.net>, Mikhail Teterin writes:
>Why don't we admit this possibility exists (as well as many others,
>perhaps) for a local user to cause a DoS and may be someday someone
>will address it?
Because we have (counts for a moment, but as he flips to the
Just review the thread:
>. Look, here is a little script, which allows any user
to perform a DoS attack!
<. Khmm, yes indeed, but you can remove any user who does
this.
>. But shouldn't the system be able to sustain/detect this
sort of att
Hi:
I just wanted to say that I see this as very important work. BSD and
Linux interoperability is the best way to insure the BSDs survive (and maybe
better) the Linux mania.
Rick Whitesel
NBase-Xyplex
"If it is easy it probably sucks."
- Original Message -
From: UCHIYAMA Yasushi
Chris Costello once stated:
=On Sat, Apr 10, 1999, Matthew Dillon wrote:
=> :Sun has a product for this, Solaris Resource Manager.
= You don't need to tune user accounts, you need only put the
=users in a separate login class (if that hasn't already been
=done) and modify the resource limitatio
Matthew Dillon wrote:
>
> I would note that BEST.COM has been running, effectively, public shell
> systems for 5 years. The last couple of years have been using FreeBSD.
> It works just dandy. We put 2000 users on each box.
>
> Just because people aren't willing to spend thousa
:What you really mean is that "FreeBSD is not a solution for public
:shell systems", correct? Public shell systems is not a bad idea,
:it's a business opportunity and a public service. If the OS is not
:up to the task, don't blame the task.
:
:--
:Daniel C. Sobral (8-DCS)
On Tue, Apr 13, 1999, Daniel C. Sobral wrote:
> What you really mean is that "FreeBSD is not a solution for public
> shell systems", correct? Public shell systems is not a bad idea,
> it's a business opportunity and a public service. If the OS is not
> up to the task, don't blame the task.
If y
> What you really mean is that "FreeBSD is not a solution for public
> shell systems", correct? Public shell systems is not a bad idea,
> it's a business opportunity and a public service. If the OS is not
> up to the task, don't blame the task.
Any Unix OS is going to give you more or less the sam
Chris Costello wrote:
>
> > If one can't control one's users, one has no business managing them.
> > The
> > last thing FreeBSD needs is some overly complex, sophisticated scheduler
> > designed to help bozo sysops stay on their feet.
>
>I agree with you very much here. Public
Thomas Schuerger wrote:
>
> I have Win95 and FreeBSD 4.0-Current on my system.
What version of FreeBSD you originally had in your system?
> Today I had to reinstall Win95, which overwrites the master boot record.
> After that I used fdisk to switch to FreeBSD and used /stand/sysinstall
> to inst
It seems that as of today (13 Apr) make -j N world works fine.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Hi!
I have Win95 and FreeBSD 4.0-Current on my system.
Today I had to reinstall Win95, which overwrites the master boot record.
After that I used fdisk to switch to FreeBSD and used /stand/sysinstall
to install the FreeBSD selector boot record (I set the FreeBSD and the
Win95 partition to bootabl
ftp://ftp.nop.or.jp/users/uch/PCMCIA/FreeBSD/sys4c990410-newconfig990413.patch.gz
This is newest newconfig patch against to 4.0-CURRENT(990410).
FreeBSD/newconfig provides NetBSD compatible frame work ,bus_space(9)
(bus_memio.h,bus_pio.h are no longer required.) and `bus name`_intr_establish.
a
On Mon, 12 Apr 1999, Alfred Perlstein wrote:
> On Mon, 12 Apr 1999, Doug Rabson wrote:
>
> > On Mon, 12 Apr 1999, Alfred Perlstein wrote:
> >
> > > The problem that i faced was that the console stuff must be done even
> > > before the SYSINITs are done it's generally setup from machdep.c this
>
?
Alfred Perlstein wrote:
> On Mon, 12 Apr 1999, Maxim Sobolev wrote:
>
> > Alfred Perlstein wrote:
> >
> > > Hey, i was just doing a kernel compile over NFS and i have a weird
> > > situtation.? After compiling everything the linker barfs on linking.
> > >
> > > gensetdefs: cd9660_bmap.o: not an
56 matches
Mail list logo
