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

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>

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

> Thomas E. Spanjaard <tgen@netphreax.net> 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 <corecode@fs.ei.tum.de> 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

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
	tgen@netphreax.net
	tgen@deepbone.net

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

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?