Menu
▾
▴
freemint-discuss — The official FreeMiNT Mailing List
You can subscribe to this list here.
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(30) |
Dec
(10) |
| 2018 |
Jan
(44) |
Feb
(44) |
Mar
(32) |
Apr
(49) |
May
(45) |
Jun
(7) |
Jul
(15) |
Aug
(84) |
Sep
(95) |
Oct
(36) |
Nov
(88) |
Dec
(41) |
| 2019 |
Jan
(21) |
Feb
(27) |
Mar
(67) |
Apr
(25) |
May
(69) |
Jun
(45) |
Jul
(65) |
Aug
(15) |
Sep
(20) |
Oct
(42) |
Nov
(109) |
Dec
(62) |
| 2020 |
Jan
(58) |
Feb
(36) |
Mar
(84) |
Apr
(169) |
May
(325) |
Jun
(267) |
Jul
(43) |
Aug
(3) |
Sep
(27) |
Oct
(25) |
Nov
(25) |
Dec
(7) |
| 2021 |
Jan
(11) |
Feb
(66) |
Mar
(1) |
Apr
(55) |
May
(24) |
Jun
(36) |
Jul
(10) |
Aug
|
Sep
(1) |
Oct
(21) |
Nov
(2) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(98) |
Mar
(15) |
Apr
(31) |
May
(4) |
Jun
(23) |
Jul
(45) |
Aug
(15) |
Sep
(75) |
Oct
(8) |
Nov
(10) |
Dec
(12) |
| 2023 |
Jan
(5) |
Feb
(49) |
Mar
(31) |
Apr
(3) |
May
(7) |
Jun
(5) |
Jul
(7) |
Aug
(161) |
Sep
(8) |
Oct
(7) |
Nov
(27) |
Dec
(26) |
| 2024 |
Jan
(24) |
Feb
(35) |
Mar
(11) |
Apr
(38) |
May
(13) |
Jun
(39) |
Jul
(2) |
Aug
(24) |
Sep
(7) |
Oct
(5) |
Nov
|
Dec
(18) |
| 2025 |
Jan
(82) |
Feb
(11) |
Mar
(9) |
Apr
(13) |
May
(2) |
Jun
(7) |
Jul
(2) |
Aug
(38) |
Sep
(46) |
Oct
(13) |
Nov
(3) |
Dec
|
|
From: Vincent R. <vin...@fr...> - 2018-04-21 14:58:23
|
On 21/04/2018 at 16:53, David Gálvez wrote: > "#if !(defined(M68000) || defined(__mcoldfire__))") IIRC (not sure): - defined(M68000) means: "we are building the MINT000.PRG" - defined(__mcoldfire__) means: "we are building the MINTV4E.PRG" (as we don't have a specific define) A specific define can be useful when building several kernels with the same CPU options (which definitely happens in EmuTOS). -- Vincent Rivière |
|
From: David G. <dga...@gm...> - 2018-04-21 14:53:31
|
2018-03-22 13:50 GMT+01:00 David Gálvez <dga...@gm...>: > 2018-02-19 10:02 GMT+01:00 David Gálvez <dga...@gm...>: >> 2018-02-19 9:45 GMT+01:00 David Gálvez <dga...@gm...>: >>> Move this discussion from github to the list. >>> >>> So if I understand correctly __M680x0__ (with uppercase) is MiNT's >>> specific and it's deprecated, I've seen 7 use instances in the >>> kernel's code, by coincidence 4 in files I'm working with right now, >>> then the alternative is the compiler general __mc680x0__ (with lower >>> case), but it's still no clear to me what is state of these macros in >>> gcc 7. Can use them safely? >>> >>> >> >> I have just read this in the gcc 7.3.0 manual: >> >> "GCC defines the macros __mcarch and __mcarch__ when tuning for 680x0 >> architecture arch. It also defines mcarch unless either -ansi or a >> non-GNU -std option is used. If GCC is tuning for a range of >> architectures, as selected by -mtune=68020-40 or -mtune=68020-60, it >> defines the macros for every architecture in the range." >> >> So in theory it's safe and nothing has been changed regarding these >> macros between compiler's version. >> >> I'm going to remove what is left of the uppercase macros and swap them >> by the lowercase ones >> > > I've now replaced the old MiNT's specific macros by the generic ones. > I've left untouched the M680x0 macros (without underscores) that are > defined during the compile's time (see KERNELDEFS). > Those seems to have some extra purpose, for example the macro M68040 > is defined when compiling the ColdFire kernel. > > Still there are some defines that mix both macros types (like this one > "#if !(defined(M68000) || defined(__mcoldfire__))") > https://github.com/freemint/freemint/blob/1196c6f665b6eed314b419ce560f445ebaeae5a1/sys/arch/intr.S#L749 > If this is not on purpose we could replace them too for code consistency. The commit broke things. When compiling with -m68060 the __M68020__ macro is defined but not the __mc68020__, so replace one for the other wasn't a good idea. Now to fix this I have doubts if using the M680x0 macros (without underscores) defined in KERNELDEFS or the ones defined by the compiler. |
|
From: David G. <dga...@gm...> - 2018-04-19 15:05:52
|
2018-04-19 11:15 GMT+02:00 Thorsten Otto <ad...@th...>:
> On Donnerstag, 19. April 2018 10:10:33 CEST David Gálvez wrote:
>> I've seen that sigmask is in a different position only in Linux-m68k
>> kernel headers files, but in glibc and NetBSD
>> is in the same location than in MiNTlib:
>
> But the installed header file is machine dependent (it's a copy of sysdeps/
> unix/sysv/linux/{arch}/sys/ucontext.h from the source archive), and the one
> you are quoting there is not the one used for linux/m68k.
>
Yes, you're right, I missed the Linux specific ucontext.h file in the
GNU C lib sources.
The one I linked here it was machine dependent too
"sysdeps/m68k/sys/ucontext.h",
but of course not what the glibc is installing in Linux-m68k.
I've also seen that the "generic" glibc ucontext struct in
"sysdeps/generic/sys" also
moved the sigmask to the end of the struct.
>>Do you have in mind an example
>>of a possible situation where having the registers
>>in different positions in the struct would affect portability.
>
> My goal would be to actually implement that functionality, both in the library
> and in the kernel. Actually i think it does not matter much how the structure
> is actually implemented, but it would make sense to use the same structure for
> both, so that the library does not have to make a copy of it. And for that it
> should be defined in a way that future enhancements are easier (e.g. more than
> 32 signals numbers).
>
I think that makes sense.
|
|
From: Thorsten O. <ad...@th...> - 2018-04-19 09:15:49
|
On Donnerstag, 19. April 2018 10:10:33 CEST David Gálvez wrote:
> I've seen that sigmask is in a different position only in Linux-m68k
> kernel headers files, but in glibc and NetBSD
> is in the same location than in MiNTlib:
But the installed header file is machine dependent (it's a copy of sysdeps/
unix/sysv/linux/{arch}/sys/ucontext.h from the source archive), and the one
you are quoting there is not the one used for linux/m68k.
>My guess is that portable software is using glibc instead the Linux
>kernel headers file.
Well that structure isn't really portable. And IIRC correctly its not even
defined in kernel headers.
Given that the functions aren't implement in Mintlib, and that the kernel does
not pass the information to signal handlers, it is unlikely that any existing
software for MiNT makes use of that structure.
>Do you have in mind an example
>of a possible situation where having the registers
>in different positions in the struct would affect portability.
My goal would be to actually implement that functionality, both in the library
and in the kernel. Actually i think it does not matter much how the structure
is actually implemented, but it would make sense to use the same structure for
both, so that the library does not have to make a copy of it. And for that it
should be defined in a way that future enhancements are easier (e.g. more than
32 signals numbers).
>"POSIX.1-2004 obsoleted these functions, and in POSIX.1-2008 they were
>removed, with POSIX Threads indicated as a possible replacement"
... the only problem being that there is no such thing as a posix-compliant
thread library for mint, which is a really stopper for a lot of modern
applications. A lot of them don't even compile when pthread.h is not
available.
|
|
From: David G. <dga...@gm...> - 2018-04-19 08:10:41
|
Hi Thorsten, I did some research about this, below what I've found out.
2018-04-07 16:25 GMT+02:00 Thorsten Otto <ad...@th...>:
> While experimenting with some code, i noticed that our struct ucontext in sys/
> ucontext_h is similar, but not identical to the one from linux/m68k.
>
> The main differences are that, in the general registers, R_PC/R_PS (i think
> that should be the status register?) are reversed, the sigmask is at a
> different location (maybe because on linux a complete set it is more than just
> a long), and the layout of the floating point register set is different. Would
> it be a problem to reorder them? That could make porting some software much
> easier. As far as i can tell, although that structure is defined, it is
> nowhere used: {get,set,make,swap}context are not implemented, and SA_SIGINFO
> isn't either.
>
I've seen that sigmask is in a different position only in Linux-m68k
kernel headers files, but in glibc and NetBSD
is in the same location than in MiNTlib:
glibc:
/* Userlevel context. */
typedef struct ucontext_t
{
unsigned long int __ctx(uc_flags);
struct ucontext_t *uc_link;
sigset_t uc_sigmask;
stack_t uc_stack;
mcontext_t uc_mcontext;
long int __glibc_reserved1[201];
} ucontext_t;
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/m68k/sys/ucontext.h;h=14232d268ae7147239bfb7c4c9681036240e8d0b;hb=f55a4fdefb00837f2e2a77c04792e69e888ead3e#l112
NetBSD:
typedef struct __ucontext ucontext_t;
struct __ucontext {
unsigned int uc_flags; /* properties */
ucontext_t * uc_link; /* context to resume */
sigset_t uc_sigmask; /* signals blocked in this context */
stack_t uc_stack; /* the stack used by this context */
mcontext_t uc_mcontext; /* machine state */
#if defined(_UC_MACHINE_PAD)
long __uc_pad[_UC_MACHINE_PAD];
#endif
};
https://github.com/NetBSD/src/blob/4a985cb82ed80063a586ae42790a829e2ec7a59b/sys/sys/ucontext.h#L38
My guess is that portable software is using glibc instead the Linux
kernel headers file.
So I wouldn't change anything regarding the sigmask position in the
ucontext struct.
The PC and PS registers are switched in MiNTlib in relation with glibc
and NetBSD,
also fpregset differs in MiNTlib from glibc and NetBSD but I've found
this in the GNU C lib documentation:
"mcontext_t uc_mcontext
This element contains the actual state of the process. The mcontext_t
type is also defined in this header but
the definition should be treated as opaque. Any use of knowledge of
the type makes applications less portable."
http://www.gnu.org/software/libc/manual/html_node/System-V-contexts.html
So I think I wouldn't change anything. Do you have in mind an example
of a possible situation where having the registers
in different positions in the struct would affect portability.
By the way as a curiosity during my research I've read that all these
things are deprecated in the POSIX specification:
"POSIX.1-2004 obsoleted these functions, and in POSIX.1-2008 they were
removed, with POSIX Threads indicated as a possible replacement"
|
|
From: Thorsten O. <ad...@th...> - 2018-04-16 14:10:41
|
On Montag, 16. April 2018 15:33:24 CEST Mark Duckworth wrote: > But why? Is this is because they think nobody uses it or because it is > holding back the binutils codebase? If the former, we could push to > keep it. I think this is because nobody at FSF actively maintains it. And of course it is more work when doing general code changes that affect all targets. There was a question about this removal about a year ago already, now it has come true :( As long as only binutils is affected, this not a real problem for us i think. It is unlikely that any new features are ported to a.out anyway, so we can just stick to the current (2.30) version. It will only become a problem if the compiler starts to spit out mnemonics that our assembler does not understand. Another possibility is to add the removed parts back in our patch, as for now that should not be a big deal (we don't have to care about coff, or parts specific to other hosts; also the patches for the testsuite could be omitted since that part can never be run by a cross-compiler, and i think that it has not been run for a long time on real hardware. |
|
From: Mark D. <mdu...@at...> - 2018-04-16 13:54:53
|
But why? Is this is because they think nobody uses it or because it is holding back the binutils codebase? If the former, we could push to keep it. Thanks, Mark On 04/16/2018 05:23 AM, Thorsten Otto wrote: > As seen on the binutils mailing list: > > ---------- Forwarded Message ---------- > > Subject: Remove m68k-aout and m68k-coff support > Date: Montag, 16. April 2018, 08:24:46 CEST > From: Alan Modra <am...@gm...> > To: bin...@so... > > include/ > * aout/host.h: Remove m68k-aout and m68k-coff support. > * aout/hp300hpux.h: Delete. > * coff/apollo.h: Delete. > * coff/aux-coff.h: Delete. > * coff/m68k.h: Delete. > bfd/ > * Makefile.am: Remove m68k-aout and m68k-coff support. > * aoutf1.h: Likewise. > * aoutx.h: Likewise. > * archive.c: Likewise. > * bfd-in.h: Likewise. > * bfd.c: Likewise. > * coffcode.h: Likewise. > * coffswap.h: Likewise. > * config.bfd: Likewise. > * configure.ac: Likewise. > * configure.host: Likewise. > * doc/bfd.texinfo: Likewise. > * doc/bfdint.texi: Likewise. > * freebsd.h: Likewise. > * gen-aout.c: Likewise. > * hpux-core.c: Likewise. > * libaout.h: Likewise. > * libbfd-in.h: Likewise. > * pdp11.c: Likewise. > * peicode.h: Likewise. > * riscix.c: Likewise. > * targets.c: Likewise. > * aout0.c: Delete. > * coff-apollo.c: Delete. > * coff-aux.c: Delete. > * coff-m68k.c: Delete. > * coff-svm68k.c: Delete. > * coff-u68k.c: Delete. > * hosts/delta68.h: Delete. > * hosts/hp300bsd.h: Delete. > * hosts/m68kaux.h: Delete. > * hosts/news.h: Delete. > * hp300bsd.c: Delete. > * hp300hpux.c: Delete. > * liboasys.h: Delete. > * m68k4knetbsd.c: Delete. > * m68klinux.c: Delete. > * m68knetbsd.c: Delete. > * oasys.c: Delete. > * versados.c: Delete. > * Makefile.in: Regenerate. > * bfd-in2.h: Regenerate. > * configure: Regenerate. > * libbfd.h: Regenerate. > * po/SRC-POTFILES.in: Regenerate. > binutils/ > * testsuite/binutils-all/copy-2.d: Remove m68k-aout and m68k-coff > support. > * testsuite/binutils-all/copy-3.d: Likewise. > * testsuite/binutils-all/objcopy.exp: Likewise. > * testsuite/lib/binutils-common.exp: Likewise. > gas/ > * Makefile.am: Remove m68k-aout and m68k-coff support. > * config/tc-m68k.c: Likewise. > * config/tc-m68k.h: Likewise. > * configure.ac: Likewise. > * configure.tgt: Likewise. > * testsuite/gas/all/weakref1u.d: Likewise. > * testsuite/gas/m68k/all.exp: Likewise. > * testsuite/gas/m68k/br-isaa.d: Likewise. > * testsuite/gas/m68k/br-isab.d: Likewise. > * testsuite/gas/m68k/br-isac.d: Likewise. > * config/te-psos.h: Delete. > * config/te-sun3.h: Delete. > * testsuite/gas/m68k-coff/gas.exp: Delete. > * testsuite/gas/m68k-coff/p2389.s: Delete. > * testsuite/gas/m68k-coff/p2389a.s: Delete. > * testsuite/gas/m68k-coff/p2430.s: Delete. > * testsuite/gas/m68k-coff/p2430a.s: Delete. > * testsuite/gas/m68k-coff/t1.s: Delete. > * testsuite/gas/m68k/p3041.d: Delete. > * testsuite/gas/m68k/p3041.s: Delete. > * testsuite/gas/m68k/p3041data.d: Delete. > * testsuite/gas/m68k/p3041data.s: Delete. > * testsuite/gas/m68k/p3041pcrel.d: Delete. > * testsuite/gas/m68k/p3041pcrel.s: Delete. > * testsuite/gas/m68k/t2.d: Delete. > * Makefile.in: Regenerate. > * config.in: Regenerate. > * configure: Regenerate. > * po/POTFILES.in: Regenerate. > ld/ > * Makefile.am: Remove m68k-aout and m68k-coff support. > * configure.tgt: Likewise. > * emultempl/m68kelf.em: Likewise. > * ld.texinfo: Likewise. > * mri.c: Likewise. > * emulparams/delta68.sh: Delete. > * emulparams/hp300bsd.sh: Delete. > * emulparams/hp3hpux.sh: Delete. > * emulparams/m68k4knbsd.sh: Delete. > * emulparams/m68kaout.sh: Delete. > * emulparams/m68kaux.sh: Delete. > * emulparams/m68kcoff.sh: Delete. > * emulparams/m68klinux.sh: Delete. > * emulparams/m68knbsd.sh: Delete. > * emulparams/m68kpsos.sh: Delete. > * emulparams/sun3.sh: Delete. > * emultempl/m68kcoff.em: Delete. > * scripttempl/delta68.sc: Delete. > * scripttempl/m68kaux.sc: Delete. > * scripttempl/m68kcoff.sc: Delete. > * scripttempl/psos.sc: Delete. > * testsuite/ld-versados/t1-1.ro: Delete. > * testsuite/ld-versados/t1-2.ro: Delete. > * testsuite/ld-versados/t1.ld: Delete. > * testsuite/ld-versados/t1.ook: Delete. > * testsuite/ld-versados/t2-1.ro: Delete. > * testsuite/ld-versados/t2-2.ro: Delete. > * testsuite/ld-versados/t2-3.ro: Delete. > * testsuite/ld-versados/t2.ld: Delete. > * testsuite/ld-versados/t2.ook: Delete. > * testsuite/ld-versados/versados.exp: Delete. > * Makefile.in: Regenerate. > * po/BLD-POTFILES.in: Regenerate. > > Alan Modra > Australia Development Lab, IBM > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: Thorsten O. <ad...@th...> - 2018-04-16 09:23:24
|
As seen on the binutils mailing list: ---------- Forwarded Message ---------- Subject: Remove m68k-aout and m68k-coff support Date: Montag, 16. April 2018, 08:24:46 CEST From: Alan Modra <am...@gm...> To: bin...@so... include/ * aout/host.h: Remove m68k-aout and m68k-coff support. * aout/hp300hpux.h: Delete. * coff/apollo.h: Delete. * coff/aux-coff.h: Delete. * coff/m68k.h: Delete. bfd/ * Makefile.am: Remove m68k-aout and m68k-coff support. * aoutf1.h: Likewise. * aoutx.h: Likewise. * archive.c: Likewise. * bfd-in.h: Likewise. * bfd.c: Likewise. * coffcode.h: Likewise. * coffswap.h: Likewise. * config.bfd: Likewise. * configure.ac: Likewise. * configure.host: Likewise. * doc/bfd.texinfo: Likewise. * doc/bfdint.texi: Likewise. * freebsd.h: Likewise. * gen-aout.c: Likewise. * hpux-core.c: Likewise. * libaout.h: Likewise. * libbfd-in.h: Likewise. * pdp11.c: Likewise. * peicode.h: Likewise. * riscix.c: Likewise. * targets.c: Likewise. * aout0.c: Delete. * coff-apollo.c: Delete. * coff-aux.c: Delete. * coff-m68k.c: Delete. * coff-svm68k.c: Delete. * coff-u68k.c: Delete. * hosts/delta68.h: Delete. * hosts/hp300bsd.h: Delete. * hosts/m68kaux.h: Delete. * hosts/news.h: Delete. * hp300bsd.c: Delete. * hp300hpux.c: Delete. * liboasys.h: Delete. * m68k4knetbsd.c: Delete. * m68klinux.c: Delete. * m68knetbsd.c: Delete. * oasys.c: Delete. * versados.c: Delete. * Makefile.in: Regenerate. * bfd-in2.h: Regenerate. * configure: Regenerate. * libbfd.h: Regenerate. * po/SRC-POTFILES.in: Regenerate. binutils/ * testsuite/binutils-all/copy-2.d: Remove m68k-aout and m68k-coff support. * testsuite/binutils-all/copy-3.d: Likewise. * testsuite/binutils-all/objcopy.exp: Likewise. * testsuite/lib/binutils-common.exp: Likewise. gas/ * Makefile.am: Remove m68k-aout and m68k-coff support. * config/tc-m68k.c: Likewise. * config/tc-m68k.h: Likewise. * configure.ac: Likewise. * configure.tgt: Likewise. * testsuite/gas/all/weakref1u.d: Likewise. * testsuite/gas/m68k/all.exp: Likewise. * testsuite/gas/m68k/br-isaa.d: Likewise. * testsuite/gas/m68k/br-isab.d: Likewise. * testsuite/gas/m68k/br-isac.d: Likewise. * config/te-psos.h: Delete. * config/te-sun3.h: Delete. * testsuite/gas/m68k-coff/gas.exp: Delete. * testsuite/gas/m68k-coff/p2389.s: Delete. * testsuite/gas/m68k-coff/p2389a.s: Delete. * testsuite/gas/m68k-coff/p2430.s: Delete. * testsuite/gas/m68k-coff/p2430a.s: Delete. * testsuite/gas/m68k-coff/t1.s: Delete. * testsuite/gas/m68k/p3041.d: Delete. * testsuite/gas/m68k/p3041.s: Delete. * testsuite/gas/m68k/p3041data.d: Delete. * testsuite/gas/m68k/p3041data.s: Delete. * testsuite/gas/m68k/p3041pcrel.d: Delete. * testsuite/gas/m68k/p3041pcrel.s: Delete. * testsuite/gas/m68k/t2.d: Delete. * Makefile.in: Regenerate. * config.in: Regenerate. * configure: Regenerate. * po/POTFILES.in: Regenerate. ld/ * Makefile.am: Remove m68k-aout and m68k-coff support. * configure.tgt: Likewise. * emultempl/m68kelf.em: Likewise. * ld.texinfo: Likewise. * mri.c: Likewise. * emulparams/delta68.sh: Delete. * emulparams/hp300bsd.sh: Delete. * emulparams/hp3hpux.sh: Delete. * emulparams/m68k4knbsd.sh: Delete. * emulparams/m68kaout.sh: Delete. * emulparams/m68kaux.sh: Delete. * emulparams/m68kcoff.sh: Delete. * emulparams/m68klinux.sh: Delete. * emulparams/m68knbsd.sh: Delete. * emulparams/m68kpsos.sh: Delete. * emulparams/sun3.sh: Delete. * emultempl/m68kcoff.em: Delete. * scripttempl/delta68.sc: Delete. * scripttempl/m68kaux.sc: Delete. * scripttempl/m68kcoff.sc: Delete. * scripttempl/psos.sc: Delete. * testsuite/ld-versados/t1-1.ro: Delete. * testsuite/ld-versados/t1-2.ro: Delete. * testsuite/ld-versados/t1.ld: Delete. * testsuite/ld-versados/t1.ook: Delete. * testsuite/ld-versados/t2-1.ro: Delete. * testsuite/ld-versados/t2-2.ro: Delete. * testsuite/ld-versados/t2-3.ro: Delete. * testsuite/ld-versados/t2.ld: Delete. * testsuite/ld-versados/t2.ook: Delete. * testsuite/ld-versados/versados.exp: Delete. * Makefile.in: Regenerate. * po/BLD-POTFILES.in: Regenerate. Alan Modra Australia Development Lab, IBM |
|
From: Peter S. <p....@sc...> - 2018-04-08 11:33:00
|
I am trying to mount a FAT partition /g/photos with Samba. When I try to access it from the ubuntu box it fails and I think it is because of the lack of permissions on the folder. It will access /tmp ok. So I created a sym link /tmp/MyPhotos pointing to /g/photos but that doesn't work either. Has anyone done this ? Peter |
|
From: Thorsten O. <ad...@th...> - 2018-04-07 14:25:39
|
While experimenting with some code, i noticed that our struct ucontext in sys/
ucontext_h is similar, but not identical to the one from linux/m68k.
The main differences are that, in the general registers, R_PC/R_PS (i think
that should be the status register?) are reversed, the sigmask is at a
different location (maybe because on linux a complete set it is more than just
a long), and the layout of the floating point register set is different. Would
it be a problem to reorder them? That could make porting some software much
easier. As far as i can tell, although that structure is defined, it is
nowhere used: {get,set,make,swap}context are not implemented, and SA_SIGINFO
isn't either.
|
|
From: David G. <dga...@gm...> - 2018-03-28 05:28:43
|
2018-03-27 18:13 GMT+02:00 Peter Slegg <p....@sc...>: > > I am using Mint build 976 and I am able to mount my mem sticks again > but it won't let me delete files and also gives FAT errors about > illegal successor ... to cluster ... > > Also, it won't "eject" the mem stick either. > This driver needs some work, the fact that only works with debug messages enable........ It's in my TODO list, when I have the time I'll send you some modules for you to try (if you can of course). |
|
From: Peter S. <p....@sc...> - 2018-03-27 16:13:29
|
I am using Mint build 976 and I am able to mount my mem sticks again but it won't let me delete files and also gives FAT errors about illegal successor ... to cluster ... Also, it won't "eject" the mem stick either. Peter |
|
From: Peter S. <p....@sc...> - 2018-03-27 13:37:54
|
On Tue, 27 Mar 2018 13:33:18 , Peter Slegg <p....@sc...> wrote: > This is odd in Thing 1.50 > > I am selecting files by dragging the mouse about half-way down > a list in a folder but after the 16th file the number of > selected objects shows zero. > > I've never seen this before. > > > Peter > I think this is due to an issue with the display of the bytes. You will notice it shows 112.261.3732 The last portion is 4 digits when it should be 3. It would be nice if it used the TOS delimiter settings as well. Peter |
|
From: Peter S. <p....@sc...> - 2018-03-27 13:33:38
|
This is odd in Thing 1.50 I am selecting files by dragging the mouse about half-way down a list in a folder but after the 16th file the number of selected objects shows zero. I've never seen this before. Peter |
|
From: Peter S. <p....@sc...> - 2018-03-26 13:32:43
|
Myself and others have reported timezone issues especially with the change to summertime. Android has a bug that means files sent over samba have their timestamps set to the sysdate. So I use touch -t to reset the times based on the filename. I have hacked up a perl script to do this. I do the mp4 files individually: touch -t 201712101030 /tmp/20171210_103049.mp4 but in Thing they are shown with a time of 1 hour ahead. I am using BST (GMT +1) In this example the file is shown as 11:30 when I have stamped it 10:30 In bash the file time is correct: bash-4.3# ls -l /tmp/ total 10460 -rw-r--r-- 1 root root 10692187 Dec 10 10:30 20171210_103049.mp4 Peter |
|
From: David G. <dga...@gm...> - 2018-03-22 12:50:14
|
2018-02-19 10:02 GMT+01:00 David Gálvez <dga...@gm...>: > 2018-02-19 9:45 GMT+01:00 David Gálvez <dga...@gm...>: >> Move this discussion from github to the list. >> >> So if I understand correctly __M680x0__ (with uppercase) is MiNT's >> specific and it's deprecated, I've seen 7 use instances in the >> kernel's code, by coincidence 4 in files I'm working with right now, >> then the alternative is the compiler general __mc680x0__ (with lower >> case), but it's still no clear to me what is state of these macros in >> gcc 7. Can use them safely? >> >> > > I have just read this in the gcc 7.3.0 manual: > > "GCC defines the macros __mcarch and __mcarch__ when tuning for 680x0 > architecture arch. It also defines mcarch unless either -ansi or a > non-GNU -std option is used. If GCC is tuning for a range of > architectures, as selected by -mtune=68020-40 or -mtune=68020-60, it > defines the macros for every architecture in the range." > > So in theory it's safe and nothing has been changed regarding these > macros between compiler's version. > > I'm going to remove what is left of the uppercase macros and swap them > by the lowercase ones > I've now replaced the old MiNT's specific macros by the generic ones. I've left untouched the M680x0 macros (without underscores) that are defined during the compile's time (see KERNELDEFS). Those seems to have some extra purpose, for example the macro M68040 is defined when compiling the ColdFire kernel. Still there are some defines that mix both macros types (like this one "#if !(defined(M68000) || defined(__mcoldfire__))") https://github.com/freemint/freemint/blob/1196c6f665b6eed314b419ce560f445ebaeae5a1/sys/arch/intr.S#L749 If this is not on purpose we could replace them too for code consistency. |
|
From: Miro K. <mir...@gm...> - 2018-03-22 03:21:44
|
Hi David,
On 22 March 2018 at 06:41, David Gálvez <dga...@gm...> wrote:
> I've just pushed a commit for generating a new RTL8012 driver version
> for machines with the 060 CPU, the new driver name is rtl8012ct60.xif.
> I guess the new driver path should be added somewhere for the binary
> snapshots (Hi Miro ;-) )
>
I followed your painful testing experience on AF so this is the least I can
do. :) Actually it's not that much work, don't be afraid to do it by
yourself in the future:
- Alan's build ("trunk") is automatically adjusted as it uses *.xif mask
to copy
- My preconfigured images needed only one small change
<https://github.com/freemint/travis-scripts/commit/a05a95dab2040c5c51fb974b748540f5c5b5bb3f>
in
'travis-scripts' repository and build restart in Travis
So now everyone can download <https://freemint.github.io/#snapshots> the
image with new driver as usual (naturally, present only in the 020 archive
in ct60 mchdir).
--
MiKRO / Mystic Bytes
http://mikro.atari.org
|
|
From: David G. <dga...@gm...> - 2018-03-21 19:42:00
|
I've just pushed a commit for generating a new RTL8012 driver version for machines with the 060 CPU, the new driver name is rtl8012ct60.xif. I guess the new driver path should be added somewhere for the binary snapshots (Hi Miro ;-) ) |
|
From: Vincent R. <vin...@fr...> - 2018-03-21 10:09:14
|
On 20/03/2018 at 21:22, Miro Kropáček wrote: > The solution is simple: use *rebase* to integrate pull requests, > instead of *merge*. > > However this doesn't solve the problem of useless/reworked commits, does > it? You just get them in a linear fashion. The contributor can be asked to rework its contribution (by adding new commits to his local branch) until the squashed commit is acceptable. Finally, there will be a single clean commit for the contribution in official sources. Of course, this applies only to relatively small changes. In case of big feature branches (which are not so common), of course a classic merge is preferable. -- Vincent Rivière |
|
From: Miro K. <mir...@gm...> - 2018-03-20 20:22:42
|
> > That gives importance to what *really* happened on the contributor's fork: > when it has been forked, when commits have really been done, or even > reworked... And usually, that's completely useless. > [...] > The solution is simple: use *rebase* to integrate pull requests, instead > of *merge*. > However this doesn't solve the problem of useless/reworked commits, does it? You just get them in a linear fashion. Of course, we could still *merge* the Pull Requests some times, when it > makes sense, but IMHO this should not be the general solution. As discussed here: https://github.com/freemint/freemint/issues/26 I'm more in favour to have a default policy (say, rebase) and if it differs, let the author to specify how he proposes to include his work. Sometimes the history is not worth it at all (i.e. squash / classic patch would work best), sometimes history is worth having as a separate branch. However Alan seems to be quite in favour of the classic merge commits. And with him being not so active it's hard to discuss matters like this and take action. :-/ > Use *rebase* in most case. Otherwise, don't complain about messy history. Well, in this case (a feature USB branch) the merge issue would stay as one would certainly prefer to use classic merge. -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Vincent R. <vin...@fr...> - 2018-03-20 10:10:06
|
On 20/03/2018 at 06:47, Miro Kropáček wrote: > Maybe someone with better git knowledge can explain the finer details? The following command gives the best view of actual log: git log --oneline --decorate --graph You can see all the commits correctly sorted, as well as merged branches with ASCII-art. This is the closer view of the reality of the history. That being said, FreeMiNT history is a mess. This is because Pull Requests are *merged*. That gives importance to what *really* happened on the contributor's fork: when it has been forked, when commits have really been done, or even reworked... And usually, that's completely useless. What is really important, is to take the contributors's patches, and include them into official sources (and history). Exactly like when the patches were contributed to the mailing list. The solution is simple: use *rebase* to integrate pull requests, instead of *merge*. I already have advocated that solution to keep a linear history, as before, and for clarity. I have applied that to EmuTOS contributions, and it worked fine. Of course, we could still *merge* the Pull Requests some times, when it makes sense, but IMHO this should not be the general solution. Use *rebase* in most case. Otherwise, don't complain about messy history. -- Vincent Rivière |
|
From: Miro K. <mir...@gm...> - 2018-03-20 05:47:49
|
Hi David, But I still don't understand why git sometime shows me Alan's branch > history and sometimes main branch history. > To be completely honest, I don't know the rules either. What I do know is that if I'm interested in a file's history the way you are and I can't use my favourite UI tool, I use "git log --first-parent --no-merges" command. That way I usually get satisfactory results without all that parent/merge commit crap. If you try it on your two files you'll see it makes much more sense now. Maybe someone with better git knowledge can explain the finer details? -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: David G. <dga...@gm...> - 2018-03-19 15:49:47
|
Hi Miro, thanks for tanking the time to explain me this so I can understand it. 2018-03-18 6:21 GMT+01:00 Miro Kropáček <mir...@gm...>: > Hi David, > > On 14 March 2018 at 10:32, David Gálvez <dga...@gm...> wrote: >> >> OK. Perhaps not very important but some differentiate commits now are >> together with others in one big commit. >> >> For example this PCI-BIOS differentiate commit: >> >> https://github.com/DavidGZ/freemint/commit/9d0a0b5701f3421bc9cc61eb352c6cedbfaf9d50#diff-ae395915bb2dac4ca2ce7c3217a8d1ab >> >> Now is mixed with some other commits with no relation: >> >> https://github.com/freemint/freemint/commit/72818b654b732896deaa31d9a686a3951b96f71a#diff-ae395915bb2dac4ca2ce7c3217a8d1ab > > That would suck a lot, wouldn't it? Fortunately, that's not the case. The > commit you're looking for is from Alan's branch. The one you have in mind is > of course in the main, master, branch all along: > https://github.com/freemint/freemint/commit/1340007b#diff-dce566b7 > > Basically it looks like this: > > commit1 -> commit2 -> commit3 (master) * -> commit 4 (still in master, your > changes) -> ... -> merge back from Alan's branch -> ... > -> > Alan's branch -> Alan's commit 4 -> ... -> Alan's merge from trunk (master, > "lots of api changes") -> ... -> merge back to master > > So you don't care what kind of merges happened in Alan's branch, he can do > whatever he likes there, only the end result (merging usbtos back to master) > matters. But I still don't understand why git sometime shows me Alan's branch history and sometimes main branch history. For example for "git log sys/kentry.c" git shows me "commit 1340007b4dd3cd98ee98f2a231df416fcbc6a1e2" from main branch: commit d1759b9c15f0253ffdbb70ad646d568563fb9e62 Author: David Gálvez <dga...@gm...> Date: Fri Feb 16 19:04:41 2018 +0100 Delete CVS's keyword $Id$ from a bunch of files This keyword is unused since the migration to Git. commit b86bf7b52f5c8b456654e8c7145d9a98eeb0d80c Author: Alan Hourihane <al...@fa...> Date: Sun Apr 26 16:16:04 2015 +0000 Export SCSIDRV interface to kentry. Contributed by David Galvez. commit f165a8f240d228cd21396ee149576f59c055aea2 Author: Alan Hourihane <al...@fa...> Date: Fri Apr 17 17:04:52 2015 +0000 Add XHDI driver to kentry structure. Contributed by David Gálvez. commit 1340007b4dd3cd98ee98f2a231df416fcbc6a1e2 Author: Alan Hourihane <al...@fa...> Date: Wed Mar 26 21:59:14 2014 +0000 Add PCI-BIOS functions to kentry. Contributed by David Galvez. commit dce566b718dd03990b378664e5f58bd341a6b198 Author: Alan Hourihane <al...@fa...> Date: Wed Mar 26 10:16:36 2014 +0000 Remove XHDI_MASS_STORAGE_SUPPORT define. Contributed by David Galvez. But for "git log sys/libkern/kernel_module.h" git shows me "commit 72818b654b732896deaa31d9a686a3951b96f71a" from Alan's branch and not the commit I mentioned above where the file was originally changed in the main branch: commit d1759b9c15f0253ffdbb70ad646d568563fb9e62 Author: David Gálvez <dga...@gm...> Date: Fri Feb 16 19:04:41 2018 +0100 Delete CVS's keyword $Id$ from a bunch of files This keyword is unused since the migration to Git. commit b86bf7b52f5c8b456654e8c7145d9a98eeb0d80c Author: Alan Hourihane <al...@fa...> Date: Sun Apr 26 16:16:04 2015 +0000 Export SCSIDRV interface to kentry. Contributed by David Galvez. commit 080a0ae516eeb6908e9789a7be5f7a3d068add3c Author: Alan Hourihane <al...@fa...> Date: Sat Apr 18 11:07:18 2015 +0000 Fix typo in structure's name, Contributed by David Gálvez. commit f165a8f240d228cd21396ee149576f59c055aea2 Author: Alan Hourihane <al...@fa...> Date: Fri Apr 17 17:04:52 2015 +0000 Add XHDI driver to kentry structure. Contributed by David Gálvez. commit 72818b654b732896deaa31d9a686a3951b96f71a Author: Alan Hourihane <al...@fa...> Date: Tue Apr 8 18:33:42 2014 +0000 Lots of API updates. Lots of TOSONLY updates. Add USB mouse driver. Merge from trunk. commit c54e4dc1b355d3c81e678b810773a8e214e96ad8 Author: Alan Hourihane <al...@fa...> Date: Thu Mar 27 18:38:58 2014 +0000 Add c_conout commit e01e106894b1618a49748bf06a9a578f037cc323 Author: Alan Hourihane <al...@fa...> Date: Mon Feb 18 23:35:32 2013 +0000 Add machine dependent module paths. Contributed by Miro Kropacek. |
|
From: Miro K. <mir...@gm...> - 2018-03-18 05:29:45
|
Hi Thorsten, On 16 March 2018 at 15:50, Thorsten Otto <ad...@th...> wrote: > Not really trouble, but some strangeness: when looking at commit > > https://github.com/freemint/freemint/commit/6794f46ceef4c45ae79c6d306c388f > 8fece03b74#diff-3240fd2b36343a7f8e388f163731ea06 > > i read now: th-otto committed on... > > However, i only committed that to my fork, and the PR was later merged. So > the information, that this commit was caused by merging that PR seems to be > lost. > But 6794f46c really is your commit. The merge commit is 147bece9, committed by Alan: -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Miro K. <mir...@gm...> - 2018-03-18 05:21:28
|
Hi David, On 14 March 2018 at 10:32, David Gálvez <dga...@gm...> wrote: > OK. Perhaps not very important but some differentiate commits now are > together with others in one big commit. > > For example this PCI-BIOS differentiate commit: > https://github.com/DavidGZ/freemint/commit/9d0a0b5701f3421bc9cc61eb352c6c > edbfaf9d50#diff-ae395915bb2dac4ca2ce7c3217a8d1ab > > Now is mixed with some other commits with no relation: > https://github.com/freemint/freemint/commit/72818b654b732896deaa31d9a686a3 > 951b96f71a#diff-ae395915bb2dac4ca2ce7c3217a8d1ab That would suck a lot, wouldn't it? Fortunately, that's not the case. The commit you're looking for is from Alan's branch. The one you have in mind is of course in the main, master, branch all along: https://github.com/freemint/freemint/commit/1340007b#diff-dce566b7 Basically it looks like this: commit1 -> commit2 -> commit3 (master) * -> commit 4 (still in master, your changes) -> ... -> merge back from Alan's branch -> ... -> Alan's branch -> Alan's commit 4 -> ... -> Alan's merge from trunk (master, "lots of api changes") -> ... -> merge back to master So you don't care what kind of merges happened in Alan's branch, he can do whatever he likes there, only the end result (merging usbtos back to master) matters. -- MiKRO / Mystic Bytes http://mikro.atari.org |
5 messages has been excluded from this view by a project administrator.
