Re: CVS commit: src/sys/sys

[Grégoire Sutre]

On 09/10/2013 10:42 PM, David Holland wrote:

On Tue, Sep 10, 2013 at 12:54:14PM +, Gr?goire Sutre wrote:
  >  Modified Files:
  >  src/sys/sys: cdefs.h
  >
  >  Log Message:
  >  Unbreak vax build (which still uses gcc 4.1).  See PR lib/48131.

Shouldn't that be conditionalized on the gcc version, then?


We would have to determine precisely which gcc version requires the
fix.  Here, I have merely restored some bits that I over-simplified
previously. (I didn't try a vax build at that time.)

Grégoire

Re: CVS commit: src/sys

[Grégoire Sutre]

On 09/18/2011 12:22 AM, Christos Zoulas wrote:


Should NULL be allowed as first argument of bus_dma_tag_create?
I would prefer for NULL to be allowed to make my life easier in
the drmgem port from OpenBSD.  But maybe requiring non-NULL would
make more sense if this shall be used from MI device drivers only?


I don't see why not, but still you need it for the scatter-gather
private data.


The sg private data can be placed in the bdt_ctx field.  At least,
it's the way I've updated the port today, but I don't pretend it's
the right way.


I've left tar files of stuff that I was playing with
(starting from your git files) on http://www.netbsd.org/~christos/


Thanks, I'll look at them.

Grégoire

Re: CVS commit: src/sys

[Grégoire Sutre]

On 09/01/2011 05:10 PM, Christos Zoulas wrote:

Module Name:src
Committed By:   christos
Date:   Thu Sep  1 15:10:32 UTC 2011

Modified Files:
src/sys/arch/i386/eisa: eisa_machdep.c
src/sys/arch/i386/mca: mca_machdep.c
src/sys/arch/x86/include: bus_private.h
src/sys/arch/x86/isa: isa_machdep.c
src/sys/arch/x86/pci: pci_machdep.c
src/sys/arch/x86/x86: bus_dma.c
src/sys/arch/xen/xen: isa_machdep.c xpci_xenbus.c
src/sys/sys: bus.h

Log Message:
Add bus_dma overrides. From dyoung


Should NULL be allowed as first argument of bus_dma_tag_create?
I would prefer for NULL to be allowed to make my life easier in
the drmgem port from OpenBSD.  But maybe requiring non-NULL would
make more sense if this shall be used from MI device drivers only?


+int
+bus_dma_tag_create(bus_dma_tag_t obdt, const uint64_t present,
+const struct bus_dma_overrides *ov, void *ctx, bus_dma_tag_t *bdtp)
  {
+   uint64_t bit, bits, nbits;
+   bus_dma_tag_t bdt;
+   const void *fp;

-   (*tag->_dmatag_destroy)(tag);
+   if (ov == NULL || present == 0)
+   return EINVAL;
+
+   bdt = kmem_alloc(sizeof(struct x86_bus_dma_tag), KM_SLEEP);
+
+   if (bdt == NULL)
+   return ENOMEM;
+
+   bdt->bdt_super = obdt;
+
+   for (bits = present; bits != 0; bits = nbits) {
+   nbits = bits&  (bits - 1);
+   bit = nbits ^ bits;
+   if ((fp = bit_to_function_pointer(ov, bit)) == NULL) {
+#ifdef DEBUG
+   printf("%s: missing bit %" PRIx64 "\n", __func__, bit);
+#endif
+   goto einval;
+   }
+   }
+
+   bdt->bdt_ov = ov;
+   bdt->bdt_exists = obdt->bdt_exists | present;


Here obdt might be NULL.

Note: bus_space_tag_create has the same issue.

Grégoire

Re: CVS commit: src/sys/arch/i386/i386

[Grégoire Sutre]

On 01/12/2011 05:09 AM, enami tsugutomo wrote:

=?UTF-8?B?R3LDqWdvaXJlIFN1dHJl?=  writes:


Assume for instance that the boot-loader left us with:

   +--+   ++ +--+
   | string table |   | kernel | | symbol table |
   +--+   ++ +--+

The new addresses computed by lines 338-359 (here, it's really
lines 344-345) will move the tables so that they end up as:

  ++--+--+
  | kernel | symbol table | string table |
  ++--+--+


If this ascii art is correct, memmove should be used instead of
memcpy.


Agreed.  I should have mentioned it in the commit message.  Here,
I just wanted to restore previous (working) behavior.

Note that the figure is just an example: afaik, no assumption can
be made regarding the placement of the tables.


Also, if initial order is kernel, string table, symbol table
and a gap between kernel and string table is smaller than symbol
table, copying it may overwrite the string table.

Is there any guarantee that the gap is large enough?


The code (that was already there) takes care of this by examining
all possible cases.  If initial order is kernel, string table,
symbol table, then the order remains the same.

Grégoire