> Technically gdbm is fine. I doubt you'll be able to displace Berkeley
> DB, though; gdbm is less buggy, but doesn't offer many of the
> features, nor does it offer equivalent performance.
>
>> I'd welcome your comments in particular, since you are an expert in
>> the field and there
>>> Well, can someone comment on the useability of gdbm? I know, it has
>>> dbm and ndbm compatibility "mode" and a less restrictive license.
>>> Should we switch over to it?
>>
>> This isn't necessary. The *current* FreeBSD libc Berkeley DB sources
>> are completely safe -- they're under
On 2001-Jul-06 18:14:03 -0700, Julian Elischer <[EMAIL PROTECTED]> wrote:
>#3 ??? (thread carrier (spindle? :-)) or thread-processor
A spindle is a physical disk drive (or at least independent head
assembly) - I/O rates are associated with spindles rather than
[virtual/RAID] disks.
If we're goi
In message <[EMAIL PROTECTED]>, Jim Bryant writes:
>
> 6:20:34pm wahoo(113): mount_msdos /dev/da0s1 /ms-dog
>mount_msdos: vfsload(msdos): No such file or directory
Try "mount_msdosfs" instead of "mount_msdos". The latter is probably
a stale binary left on your system from before the rename that
Is this a known problem?
Running -current.
options MSDOSFS #MSDOS Filesystem
6:17:42pm wahoo(111): kldstat
Id Refs AddressSize Name
11 0xc010 35ccd8 kernel
6:20:27pm wahoo(112): d /dev/da0s1
crw-r- 1 root operator 13, 0x00020002 Jul 7 20:
>From: "Ilya" <[EMAIL PROTECTED]>
>Date: Mon, 9 Jul 2001 19:05:30 -0400
>I just compiled world and kenrel for current on my laptop
>ran mergemaster
>but it seems that /dev doesnt get updated.there is no MAKEDEV there and when
>i try to copy it form my cvs to /dev i get :
>Operation not supported
hi.
I just compiled world and kenrel for current on my laptop
ran mergemaster
but it seems that /dev doesnt get updated.there is no MAKEDEV there and when
i try to copy it form my cvs to /dev i get :
Operation not supported error
there are no special flags on /dev (i chekcedk)
any suggestions?
th
Does anyone know of a place where I can find old current snapshots?
current.freebsd.org only goes back to April, and I'd like to find
something earlier. I am trying to find out why a 4.3 SMP kernel will
boot on a SuperMicro 6010H while a current kernel hangs. I am taking
the rather tedious appro
On 9 Jul, Keith Bostic wrote:
>>> My guess is that your answer remains the same -- and, that's cool,
>>> I'm used to losing this argument, I do so about twice a year. :-)
>>> Just wanted to be clear.
>>
>> Well, can someone comment on the useability of gdbm? I know, it has
>> dbm and ndb
>> Just to be clear -- they could link against it using the same,
>> standard functionality that FreeBSD uses. They couldn't link against
>> it and use all the additional features/functionality.
>
> So we'll have to document, which functions it is Ok to call and which
> arguments/flag
[moved to -current]
On 9 Jul, Keith Bostic wrote:
>> From: [EMAIL PROTECTED]
>>
>> Mmm, so there will be a library in /usr/lib, which a commercial
>> application will not be able to link against? No thanks, I'd rather
>> take gdbm and their LGPL...
>
> Just to be clear -- they could
Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Terry Lambert writes:
> : Warner Losh wrote:
> : > : The problem with this is drivers that can't share
> : > : interrupts because there is no way to ask the hardware
> : > : which of several devices caused the interrupt. This
> : > : means that
In message <[EMAIL PROTECTED]> Terry Lambert writes:
: Warner Losh wrote:
: > : The problem with this is drivers that can't share
: > : interrupts because there is no way to ask the hardware
: > : which of several devices caused the interrupt. This
: > : means that it's an attribute of the driver
Warner Losh wrote:
> : The problem with this is drivers that can't share
> : interrupts because there is no way to ask the hardware
> : which of several devices caused the interrupt. This
> : means that it's an attribute of the driver, not the
> : bus, so having the bus do this automatically woul
In message <[EMAIL PROTECTED]> Bruce Evans
writes:
: clk0 on i386 :-).
Ah, but that's extra special and not a real FreeBSD device :-)
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Mon, 9 Jul 2001, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Terry Lambert writes:
> : The problem with this is drivers that can't share
> : interrupts because there is no way to ask the hardware
> : which of several devices caused the interrupt. This
> : means that it's an attribute
In message <[EMAIL PROTECTED]> Terry Lambert writes:
: Warner Losh wrote:
: > That is, I advocate all busses that support sharing to or in
: > RF_SHAREABLE when appropriate. The trouble is that with the current
: > interfaces, that precludes one from using fast interrupts. FAST or
: > not fast i
Warner Losh wrote:
> That is, I advocate all busses that support sharing to or in
> RF_SHAREABLE when appropriate. The trouble is that with the current
> interfaces, that precludes one from using fast interrupts. FAST or
> not fast is a property of bus_setup_intr, not bus_alloc_resource. sio
>
John Baldwin wrote:
> One other note. #2 is conceptually a related group of
> #4's, so I think it's name should reflect that. (It's
> view as a group of #4's is more important than as being
> a part of #1.) So, if you go with lwp (yuck) for #4, #2
> should be lwpgrp or some such. I still think
John Baldwin wrote:
> >#3struct upctx (upcall-context), virtcpu, thrdslot (thread slot)
> >#4struct lwp(decided)
> >
> > usually the 'lwp' will be passed around so diffs to NetBSD will be
> > minimalised.
>
> One thing to note is that as Vahalia (sp?) points out, lwp
> on SVR4 and Sol
Title: 5.0 Question
I was reading the 5.0 Release notes and Hardware text. The release notes mention that usb support was added to the generic kernel and the installation program to allow for support out of the box. The hardware notes make no mention of usb cd support(unless I missed it)? Is i
This is my self follow.
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
>>I just committed Binutils 2.11.2. Please let me know if this helps or
>>not.
> Thank you! But there remain a problem about gas+ld. Linking bug.C
>(Message-Id: <[EMAIL PROTECTED]>) results error
It was "asm()"
In message <[EMAIL PROTECTED]> Terry Lambert writes:
: If cross-compilation actually worked, the people causing
: the problems for the Alpha would be able to test the
: build, with only their x86 hardware.
I think that's why you are seeing so many people trying to make it
work :-)
Warner
To Uns
Absolutely. People *are* working on getting that fixed.
On Mon, 9 Jul 2001, Terry Lambert wrote:
> Matthew Jacob wrote:
> >
> > Yes, I've actually been massaging a few of those- glad somebody's on
> > it. I'll come on out to Concord if you you need a hand It's
> > sometimes hard to keep -
Matthew Jacob wrote:
>
> Yes, I've actually been massaging a few of those- glad somebody's on
> it. I'll come on out to Concord if you you need a hand It's
> sometimes hard to keep -current up on an alpha long enough for a
> complete buildworld
If cross-compilation actually worked, the p
>> Mike Smith wrote:
> I've committed another round of ACPI changes to -current.
I cvsup'ed to FreeBSD-current after this change, but I cannot boot
kernel configured with "device acpica" (added to NEWCARD).
I can boot with the configuration NEWCARD.
In past days(cvsup'ed about 1-2 weeks ago), I
Bruce Evans <[EMAIL PROTECTED]> writes:
> On 8 Jul 2001, Dag-Erling Smorgrav wrote:
> > My -DNOPERL build broke in games/fortune in the "building everything"
> > phase because the Alpha compiler tried to use the i386 strfile.o that
> > was left over from the bootstrap phase.
> This shouldn't happe
On 8 Jul 2001, Dag-Erling Smorgrav wrote:
> Mark Peek <[EMAIL PROTECTED]> writes:
> > It probably works since i386 and pc98 are similar. I'm trying an alpha
> > cross build as we speak. So far I needed to apply this patch to get
> > around having -mcpu=ev4 being fed to the i386 compiler during th
[EMAIL PROTECTED] (Joerg Wunsch) writes:
> Do you have any further input? Does fdformat still work? Does
> "fdread -I 1" return you a sector ID?
Fdread seems to work, fdformat just hangs.
root@des ~# fdread -I 1
C = 0, H = 0, R = 2, N = 2
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Un
* Alfred Perlstein <[EMAIL PROTECTED]> [010707 16:43] wrote:
> * Seigo Tanimura <[EMAIL PROTECTED]> [010702 03:13] wrote:
> > On Mon, 18 Jun 2001 19:04:31 +0900,
> > Seigo Tanimura said:
> >
> > Seigo> The results of build test with the latest patch are now at:
> >
> > Seigo> http://people.Fr
30 matches
Mail list logo
