Gérard Roudier wrote:
> > A more recognizable reliabilty improvement is the more unified and
> > constitent programming interface. No more "you can't call malloc with
>
> This looks like matter of taste to me. Unless all O/S architects since day
> one until UDI have been incompetent idiots. :-)
Matthew Jacob wrote:
> I've been giving myself some embarrassing soul searching, and I'm
> forced to come to the conclusion that I've acted like a complete idiot
> and jerk.
>
> Robert- please accept my sincere apologies for my ill-mannered
> reaction and words. Whatever my opinions avbout UDI, w
Gérard Roudier wrote:
> Being smart with kernel interface is important for drivers to be fast and
> reliable. Puting some stinky layer between native kernel interfaces and
> drivers looks horrible to me.
Fast and reliable are both covered.
For example, the specification (though not the current
I'd mentioned a few times on this list that I had tinkered with a port
of UDI, the Uniform Driver Interface, to a FreeBSD environment while
waiting for our lawyers to get their acts together[1]. Well, I got the
final clearance and the code was released today at:
http://projectudi.sourcef
> > > there's a problem because there's no busdma for mbufs (well
> > > actually there is but it fails on really small unaligned blocks
> > > which basically breaks it for mbufs).
> >
> > Can you tell me more about this hazard? I can't control the
> > alignment that's asked for by the driver, but
Alfred Perlstein wrote:
> > So if I sandbagged the allocs to be *larger* the KMA would behave more
> > consistently with what I'd expect becuase it would then reclaim? I
> > didn't see that one coming. :-)
>
> but... this is a terrible workaround, I'm not sure it would work
> and you shouldn't
> > In this case, the resource failure isn't temporary. Once it starts
> > failing, it fails until the system is rebooted. Since this is on a
> > dedicated thread, I could handle it if it really was temporary. Of
> > course, putting me to sleep so that someone else (or even another of my
> > ow
Alfred Perlstein wrote:
> * Robert Lipe <[EMAIL PROTECTED]> [010122 09:04] wrote:
> > I'm calling contigmalloc() with M_WAITOK. For every contigmalloc, I
> > have a corresponding contigfree(). But after a few thousand cycles,
> > contigmalloc() starts retur
Hi, Gang.
I know that anytime a message starts with a subject like this, the
first reaction is to think that I've hosed the heap or am not freeing
something. While it's possible, I really don't think I have. (I also
know that everyone thinks that. :-)
I'm on FreeBSD 4.1.1. I've not seen any f
> In message <[EMAIL PROTECTED]> "Justin T. Gibbs" writes:
> :
> : RF_SHARABLE requests to share a resource with another device, not
> : within the same device. Further, RF_SHARABLE only applies to
> : IRQs, not BARs.
Warner Losh wrote:
> Actaully, the underlying RF_SHARABLE is for any region o
Hello, Hackers.
I'm on FreeBSD 4.1.1 and when I attempt multiple calls to
bus_alloc_resource on a PCI device for the same BAR, I run afoul of code
in resource_list_alloc:
rle = resource_list_find(rl, type, *rid);
if (!rle)
return 0; /* no resource of that type/rid
John Baldwin wrote:
> Unloading modules adds all sorts of new problems. Right now the WITNESS code
> will do bad bad things if you kldunload a module that contains a mutex. Even
> if the mutex is mtx_destroy'd because it still has a reference to its name in
> the internal lists it keeps.
Funny
John Baldwin wrote:
>
> On 08-Jan-01 Robert Lipe wrote:
> > I'm having problems with kthread_exit(). The problem is that the thread
> > goes zombie after I kthread_exit in it, but it never gets reaped. Since
> > I'm doing this during a MOD_UNLOAD phase, if I
Hi, Gang.
In 4.1.1, I have a pretty simple need for a kernel thread or two, but
I'm having problems with kthread_exit(). The problem is that the thread
goes zombie after I kthread_exit in it, but it never gets reaped. Since
I'm doing this during a MOD_UNLOAD phase, if I happen to do a `ps -ax'
Kenneth D. Merry wrote:
> On Mon, Nov 13, 2000 at 08:51:37 -0600, Robert Lipe wrote:
> > Kenneth D. Merry wrote:
>
> That is probably the direction you want to go in. We've got a device
> infrastructure already (new-bus), which is probably what you want to use.
This is
> > I have a need to walk the PCI bus, gleaning PCI IDs and other data.
> > (Yes, I know a dozen reasons why to NOT do that.) What I *almost*
> > need is the loop in pci_ioctl that walks pci_dev[]. The catch here is
>
> you doing things this way?
[ Answered in separate message. ]
> Are the
Kenneth D. Merry wrote:
> On Mon, Nov 13, 2000 at 00:44:10 -0600, Robert Lipe wrote:
> > I have a need to walk the PCI bus, gleaning PCI IDs and other data.
> > (Yes, I know a dozen reasons why to NOT do that.) What I *almost*
> > need is the loop in pci_ioctl that walks
I'm new to FreeBSD, but an experienced kernel guy. I'm workgin with
4.1.1 on IA32 and need help understanding the ways of your world. :-)
I'd like my project to look like a "normal" driver and use supported
interfaces, but I'll patch the core code if I need to.
I have a need to walk the PCI bus,
18 matches
Mail list logo
