headers
Pawel Jakub Dawidek | 3 Feb 2004 09:34
Picon
Favicon

Size-independent byte order swapping functions.

Hello.

I'm planning to commit this patch:

	http://garage.freebsd.pl/patches/endian.h.patch

Any comments/objections?

PS. It breaks build currently, because ATA stuff use function named
    'bswap', but I'm planing to talk with sos <at>  first about renaming it.

--

-- 
Pawel Jakub Dawidek                       http://www.FreeBSD.org
pjd <at> FreeBSD.org                           http://garage.freebsd.pl
FreeBSD committer                         Am I Evil? Yes, I Am!
Permalink | Reply | 4 comments |
headers
Ruslan Ermilov | 3 Feb 2004 10:48
Picon
Favicon

Re: Size-independent byte order swapping functions.

On Tue, Feb 03, 2004 at 09:34:44AM +0100, Pawel Jakub Dawidek wrote:
> Hello.
> 
> I'm planning to commit this patch:
> 
> 	http://garage.freebsd.pl/patches/endian.h.patch
> 
> Any comments/objections?
> 
A question: what would be their application?

Cheers,
--

-- 
Ruslan Ermilov
FreeBSD committer
ru <at> FreeBSD.org
Permalink | Reply | 0 comments |
headers
Poul-Henning Kamp | 3 Feb 2004 11:01
Picon
Favicon

Re: Size-independent byte order swapping functions.

In message <20040203083444.GM4200 <at> garage.freebsd.pl>, Pawel Jakub Dawidek write
s:

>I'm planning to commit this patch:
>
>	http://garage.freebsd.pl/patches/endian.h.patch

I have a hard time seeing a sensible use for these.

Endianess conversion is almost exclusively used in communications
(even if the "transmission media" is a disk), and I can't possibly
see how it can make sense to be lax about wordsize but strict about
byteordering.

Could you please tell us what you need these for and why you could
not use the explicitly sized families of endian functions ?

--

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk <at> FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 2 comments |
headers
Pawel Jakub Dawidek | 3 Feb 2004 11:38
Picon
Favicon

Re: Size-independent byte order swapping functions.

On Tue, Feb 03, 2004 at 11:01:55AM +0100, Poul-Henning Kamp wrote:
+> >I'm planning to commit this patch:
+> >
+> >	http://garage.freebsd.pl/patches/endian.h.patch
+> 
+> I have a hard time seeing a sensible use for these.
+> 
+> Endianess conversion is almost exclusively used in communications
+> (even if the "transmission media" is a disk), and I can't possibly
+> see how it can make sense to be lax about wordsize but strict about
+> byteordering.
+> 
+> Could you please tell us what you need these for and why you could
+> not use the explicitly sized families of endian functions ?

I found them very useful while doing many such translations.
It protect from problems when you need to manage many such transformations.

For example, you have some structure:

struct mystruct {
	uint16_t	ms_foo;
	uint32_t	ms_bar;
	uint64_t	ms_foobar;
};

and many places where you translate those fields.
Suddenly, you need to change size of one of those fields.
If you were using size-independent functions you don't need to change
anything else, in other case diff will be much bigger with much
(Continue reading)

Permalink | Reply | 1 comment |
headers
Luigi Rizzo | 3 Feb 2004 11:48

Re: Size-independent byte order swapping functions.

On Tue, Feb 03, 2004 at 11:38:04AM +0100, Pawel Jakub Dawidek wrote:
...
> +> I have a hard time seeing a sensible use for these.
> +> 
> +> Endianess conversion is almost exclusively used in communications
> +> (even if the "transmission media" is a disk), and I can't possibly
> +> see how it can make sense to be lax about wordsize but strict about
> +> byteordering.

in fact, i'd rather have some types that prevent you from
making mistakes and carelessly copy values between incompatible types.
I am exploring ways to do this -- e.g. at the moment i am using this:

	#define N(x)    ((x).__x)
	#define H16(x)  (ntohs(N(x)))
	#define H32(x)  (ntohl(N(x)))
	#define N16(x)  (htons(x))
	#define N32(x)  (htonl(x))
	 
	struct _n32_t {
		uint32_t __x;
	};

	struct _n16_t {
		uint16_t __x;
	};
	typedef struct _n32_t   n32_t;  /* network format */
	typedef struct _n16_t   n16_t;  /* network format */

so that the compiler prevents me from assigning between
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nate Lawson | 3 Feb 2004 20:14

Re: newbus ioport usage

I'm trying to get a basic version working, using rman.  Currently, I
attempt to allocate resources from the parent first, via
BUS_ALLOC_RESOURCE. If that succeeds, I add the resource to my rman pool
via rman_manage_region and return it.  If it fails, I look up the default
values for the resource with resource_list_find and then attempt to
reserve it with rman_reserve_resource.  If that succeeds, I activate the
resource and return it.  The release function just deactivates it and
always returns it to the local pool via rman_release_resource.  I set up
the initial resources by calling bus_set_resource on the acpi0 device
whenever I run into the system resources object.  This has the effect that
early allocations will come from nexus0 and later allocations (after
sysresource has been detected) come from acpi0.  I think that should be ok
for now.

A few questions:

1. Do I have to do all the bus_set_handle gyrations found in nexus?  I
thought that they could be dispensed with since nexus should do all those
when acpi0 allocates resources from it with BUS_ALLOC_RESOURCE.  I can
certainly leave out the PC98 ifdefs since I'm relatively certain there are
no PC98 ACPI machines, right?

2. Do I have to make acpi_alloc_resource/release_resource machdep now
since there are so many MD things like i386 bus handles and the like?  It
seems that nexus on all 3 archs (ia32, ia64, amd64) is exactly the same.

3. After I have gotten a resource from nexus via BUS_ALLOC_RESOURCE and
added it to the local pool through rman_manage_region, do I have to then
rman_reserve_resource before returning it to the user?
(Continue reading)

Permalink | Reply | 5 comments |
headers
M. Warner Losh | 3 Feb 2004 21:16

Re: newbus ioport usage

[[ I'll draft a longer reply this evening ]]

In message: <20040203111312.Q32201 <at> root.org>
            Nate Lawson <nate <at> root.org> writes:
: 1. Do I have to do all the bus_set_handle gyrations found in nexus?  

I think so.  I'd have to look at the code.  You may be able to  copy
the bus_handle from the BUS_ALLOC_RESOURCE resource.

: I
: thought that they could be dispensed with since nexus should do all those
: when acpi0 allocates resources from it with BUS_ALLOC_RESOURCE.

It all depends on the details (eg, I'd have to look at the code you
are writing).

: I can
: certainly leave out the PC98 ifdefs since I'm relatively certain there are
: no PC98 ACPI machines, right?

There never was or will be a ACPI implementation for pc98.

: In the future, I'll make two passes, first to detect system resource
: objects (PNP0C01 and PNP0C02) and reserve resources and the second to
: actually probe acpi devices.  I'd rather wait for newbus to do this
: multi-pass approach than attempt it myself with hacks to try to localize
: it.

Yes.  We need a better discovery phase followed by an attach phase.  I
don't know if this is a newbus API change yet or not.  I can see it
(Continue reading)

Permalink | Reply | 4 comments |
headers
Pawel Jakub Dawidek | 3 Feb 2004 22:45
Picon
Favicon

Non-standard ;; and SYSINIT().

Hello.

It looks like SYSINIT() macro is defined with trailing ;.
Maybe there was some reason to do so, but I assume that this is a bug.
There are many, many calls where an extra ; is added after SYSINIT().
SYSUNINIT() is defined without trailing ; ...

This will be ok, but ;; is not supported by ICO C (gcc -pedantic
tell me that).

Here is a patch that fix this issue at least for SYSINIT():

	http://garage.freebsd.pl/patches/SYSINIT.patch

The most important part is a change in sys/kernel.h, that removes
trailing ; from SYSINIT() definition:

-	DATA_SET(sysinit_set,uniquifier ## _sys_init);
+	DATA_SET(sysinit_set,uniquifier ## _sys_init)

AND REMEMBER! I'm not going to commit it (without strong approvals)!:)

--

-- 
Pawel Jakub Dawidek                       http://www.FreeBSD.org
pjd <at> FreeBSD.org                           http://garage.freebsd.pl
FreeBSD committer                         Am I Evil? Yes, I Am!
Permalink | Reply | 3 comments |
headers
John Baldwin | 3 Feb 2004 23:20

Re: Non-standard ;; and SYSINIT().

On Tuesday 03 February 2004 04:45 pm, Pawel Jakub Dawidek wrote:
> Hello.
>
> It looks like SYSINIT() macro is defined with trailing ;.
> Maybe there was some reason to do so, but I assume that this is a bug.
> There are many, many calls where an extra ; is added after SYSINIT().
> SYSUNINIT() is defined without trailing ; ...
>
> This will be ok, but ;; is not supported by ICO C (gcc -pedantic
> tell me that).
>
> Here is a patch that fix this issue at least for SYSINIT():
>
> 	http://garage.freebsd.pl/patches/SYSINIT.patch
>
> The most important part is a change in sys/kernel.h, that removes
> trailing ; from SYSINIT() definition:
>
> -	DATA_SET(sysinit_set,uniquifier ## _sys_init);
> +	DATA_SET(sysinit_set,uniquifier ## _sys_init)
>
> AND REMEMBER! I'm not going to commit it (without strong approvals)!:)

Yes, please.  SYSINIT() without ;'s confuse "smart" editors that try to do 
autoindent.

--

-- 
John Baldwin <john <at> baldwin.cx>  <><  http://www.baldwin.cx/~john/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nate Lawson | 4 Feb 2004 00:03

Re: newbus ioport usage

On Tue, 3 Feb 2004, M. Warner Losh wrote:
> [[ I'll draft a longer reply this evening ]]

Great.

> In message: <20040203111312.Q32201 <at> root.org>
>             Nate Lawson <nate <at> root.org> writes:
> : 1. Do I have to do all the bus_set_handle gyrations found in nexus?
>
> I think so.  I'd have to look at the code.  You may be able to  copy
> the bus_handle from the BUS_ALLOC_RESOURCE resource.

I'm not quite sure how things work but I think I shouldn't have to do any
post-processing of resources retrieved from BUS_ALLOC_RESOURCE.  The nexus
should do all the original setup and then I am just storing it in an rman
pool with rman_manage_region.  The handle may need to be regenerated when
allocating a resource out of the rman pool (later), especially if the
range changes.  For example, if I BUS_ALLOC_RESOURCE 4 I/O ports and
manage the whole region in rman, a later rman_release_resource and then
rman_reserve_resource of 1 of them should re-set the bus handle.

I can post the code if it would help.  It makes my laptop hard reset a
little ways into the boot.  ;-)  But for now, I think all I need to know
is what I need to do differently in acpi than in the nexus.  The
differences as I see it are:

1. No previous knowledge of start/end for my rman pools.  Call
rman_manage_region for each resource retrieved from nexus.

2. Try a BUS_ALLOC_RESOURCE first instead of going straight to the rman
(Continue reading)

Permalink | Reply | 3 comments |

Gmane