Bug #1555

[PATCH] dma: support Linux compilation

Added by msylvan about 5 years ago. Updated about 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

This patch modifies the minimum number of files needed to get dma to compile on
Linux. I've tried to make sure that the code should still compile unchanged on
DF, but you'd want to test before committing this, certainly.

Two things I am not sure about:

- My simplistic definition of getprogname() -- is it safe to just make it always
return "dma" ? Linux has no functional equivalent
- substituting sizeof([ph]->sa) for [ph]->sa.ss_len

Do let me know if there are any changes needed -- it'd be great to have DMA
working out-of-the-box on Linux. Also, are there any sample configuration files,
beyond the dma.8 documentation?

0001-Changes-to-dma-to-allow-for-compilation-on-Linux.patch Magnifier (3.33 KB) msylvan, 10/03/2009 05:00 PM

History

#1 Updated by corecode about 5 years ago

Michel Salim (via DragonFly issue tracker) wrote:
> - My simplistic definition of getprogname() -- is it safe to just make it always
> return "dma" ? Linux has no functional equivalent

No, you can't. dma can also act as "mailq", and should do so if called
with this name. It seems that glibc provides program_invocation_short_name.

> - substituting sizeof([ph]->sa) for [ph]->sa.ss_len

I'm not sure if this works properly. I'll see what I can do.

> Do let me know if there are any changes needed -- it'd be great to have DMA
> working out-of-the-box on Linux. Also, are there any sample configuration files,
> beyond the dma.8 documentation?

There is, but it is in the etc/ directory. I will move it.

How do you intend to work with reallocf and strlcpy? Should we include
that in the dma directory, or is there another way of doing it?

cheers
simon

#2 Updated by TGEN about 5 years ago

Simon 'corecode' Schubert wrote:
> Michel Salim (via DragonFly issue tracker) wrote:
>> - My simplistic definition of getprogname() -- is it safe to just make
>> it always
>> return "dma" ? Linux has no functional equivalent
>
> No, you can't. dma can also act as "mailq", and should do so if called
> with this name. It seems that glibc provides
> program_invocation_short_name.

What about just taking argv[0] early on?

Cheers,
--
Thomas E. Spanjaard

#3 Updated by msylvan about 5 years ago

> Thomas E. Spanjaard <> added the comment:
>
> Simon 'corecode' Schubert wrote:
>> Michel Salim (via DragonFly issue tracker) wrote:
>>> - My simplistic definition of getprogname() -- is it safe to just make
>>> it always
>>> return "dma" ? Linux has no functional equivalent
>>
>> No, you can't. dma can also act as "mailq", and should do so if called
>> with this name. It seems that glibc provides
>> program_invocation_short_name.
>
> What about just taking argv[0] early on?

That would work too. So I should also install a symlink to mailq, then.

> Simon 'corecode' Schubert <> added the comment:
> How do you intend to work with reallocf and strlcpy? Should we include
> that in the dma directory, or is there another way of doing it?
>
In the Makefile.linux, I currently just symlink the source file from
DragonFly's libc. Not sure what should be done -- those files are
*really* part of libc anyway. I'd say just leave them there. If dma
gets separated out into its own module, then provided the tarballs are
generated on a machine that has the full dfly git repo somewhere, just
script it so these two files get added to the archive.

Thanks,

--
Michel Alexandre Salim
Fedora Project

#4 Updated by uqs about 5 years ago

Shouldn't Makefile.linux be renamed to GNUmakefile so that GNU make(1) will pick
it up and prefer it over Makefile or BSDmakefile?

just food for thought

#5 Updated by corecode about 5 years ago

I forgot before to follow up: I've commited fixes to make dma compile on Linux.
Could you verify and confirm? You should be able to download a tarball from
<http://gitweb.dragonflybsd.org/dragonfly.git/snapshot/12b942762bf157d9b0596a00b57b01a719345322.tar.bz2>

#6 Updated by corecode about 5 years ago

Ulrich Spoerlein (via DragonFly issue tracker) wrote:
> Shouldn't Makefile.linux be renamed to GNUmakefile so that GNU make(1) will pick
> it up and prefer it over Makefile or BSDmakefile?

It is a generic makefile, good for any make. Also automating it too
much is of little use since the user has to specify some defines for
compilation.

cheers
simon

Also available in: Atom PDF