re: CVS commit: src/lib/libc
On Oct 16, 4:06pm, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: src/lib/libc | | Module Name:src | Committed By: christos | Date: Sat Oct 15 23:00:02 UTC 2011 | | Modified Files: | ... | src/lib/libc/gen: fstab.c fts.c getcap.c getgrent.c getttyent.c | getusershell.c initdir.c opendir.c syslog.c utmp.c utmpx.c | ... | | close on exec fixes: | - open + fcntl - open O_CLOEXEC | - configuration database file descriptors that can stay open are now opened | fopen(db, re) | | At least fts.c is used in libnbcompat, so this broke the tools build | on NetBSD 5 and probably lots of other systems. | | this should be fixed now. Thanks, but then shouldn't we also add: #if O_CLOEXEC == 0 (void)fcntl(sp-fts_rfd, F_SETFD, FD_CLOEXEC); #endif after the open? i don't understand why? .mrg.
Re: CVS commit: src/lib/libc
On Sun, Oct 16, 2011 at 01:23:38AM -0400, Christos Zoulas wrote:
...
| close on exec fixes:
| - open + fcntl - open O_CLOEXEC
...
Thanks, but then shouldn't we also add:
#if O_CLOEXEC == 0
(void)fcntl(sp-fts_rfd, F_SETFD, FD_CLOEXEC);
#endif
after the open?
In which case it would be cleaner to have something like:
#if define(O_CLOEXEC) O_CLOEXEC != 0
#define open_cloexec(name, mode) open(name, (mode) | O_CLOEXEC)
#else
static inline int
open_cloexec(const char *name, unsigned int mode)
{
int fd = open(name, mode);
if (fd = 0)
fcntl(fd, F_SETFD, 0);
return fd;
}
#endif
and the use open_clowxec() in the code.
David
--
David Laight: da...@l8s.co.uk
Re: CVS commit: src/external/public-domain/sqlite
On Sun, Oct 16, 2011 at 05:24:50PM +, Joerg Sonnenberger wrote: Module Name: src Committed By: joerg Date: Sun Oct 16 17:24:50 UTC 2011 Modified Files: src/external/public-domain/sqlite: Makefile.inc Log Message: Build with -DSQLITE_ENABLE_FTS3_PARENTHESIS pkgsrc sqlite3 also has an option for rtree - it would be nice to build that into the version in src by default. I'm not sure about the pkgsrc icu option, but that would arguably be neat as well. Best, Alistair
Re: CVS commit: src/external/public-domain/sqlite
On Sun, Oct 16, 2011 at 07:31:51PM +0200, Alistair Crooks wrote: Log Message: Build with -DSQLITE_ENABLE_FTS3_PARENTHESIS pkgsrc sqlite3 also has an option for rtree - it would be nice to build that into the version in src by default. I'm not sure about the pkgsrc icu option, but that would arguably be neat as well. icu is big. I don't think we want it in base unless we're really sure... -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/external/public-domain/sqlite
On Sun, Oct 16, 2011 at 11:57:28PM +, David Holland wrote: On Sun, Oct 16, 2011 at 07:31:51PM +0200, Alistair Crooks wrote: Log Message: Build with -DSQLITE_ENABLE_FTS3_PARENTHESIS pkgsrc sqlite3 also has an option for rtree - it would be nice to build that into the version in src by default. I'm not sure about the pkgsrc icu option, but that would arguably be neat as well. icu is big. I don't think we want it in base unless we're really sure... Yup, hence the arguably. But rtrees are much lighterweight, involve no external libraries, and would be nice to have. Regards, Alistair
Re: CVS commit: src/external/public-domain/sqlite
On Sun, Oct 16, 2011 at 07:31:51PM +0200, Alistair Crooks wrote: On Sun, Oct 16, 2011 at 05:24:50PM +, Joerg Sonnenberger wrote: Module Name:src Committed By: joerg Date: Sun Oct 16 17:24:50 UTC 2011 Modified Files: src/external/public-domain/sqlite: Makefile.inc Log Message: Build with -DSQLITE_ENABLE_FTS3_PARENTHESIS pkgsrc sqlite3 also has an option for rtree - it would be nice to build that into the version in src by default. I'm not sure about the pkgsrc icu option, but that would arguably be neat as well. Feel free to add the option. ICU has external dependencies, but the default build does include support for loadable extensions, so it could still be provided via pkgsrc... Joerg
Re: CVS commit: src/external/public-domain/sqlite
On Mon, Oct 17, 2011 at 04:19:00AM +0200, Joerg Sonnenberger wrote: On Sun, Oct 16, 2011 at 07:31:51PM +0200, Alistair Crooks wrote: On Sun, Oct 16, 2011 at 05:24:50PM +, Joerg Sonnenberger wrote: Module Name: src Committed By: joerg Date: Sun Oct 16 17:24:50 UTC 2011 Modified Files: src/external/public-domain/sqlite: Makefile.inc Log Message: Build with -DSQLITE_ENABLE_FTS3_PARENTHESIS pkgsrc sqlite3 also has an option for rtree - it would be nice to build that into the version in src by default. I'm not sure about the pkgsrc icu option, but that would arguably be neat as well. Feel free to add the option. ICU has external dependencies, but the default build does include support for loadable extensions, so it could still be provided via pkgsrc... Well, if there's no cogent disagreement, I will, thanks. And if you could make a builtin.mk for pkgsrc's sqlite3 entry, that would also be great. Thanks, Alistair
Re: CVS commit: src/sys/dev/ata
On Feb 25, 1:28pm, Wolfgang Solfrank wrote: } Jonathan A. Kollasch schrieb: } On Wed, Oct 05, 2011 at 10:25:52AM +0200, Manuel Bouyer wrote: } On Wed, Oct 05, 2011 at 03:40:18AM +, Jonathan A. Kollasch wrote: } Module Name: src } Committed By: jakllsch } Date: Wed Oct 5 03:40:18 UTC 2011 } } Modified Files: }src/sys/dev/ata: wd.c } } Log Message: } Limit wd(4) transfers to 128 (512-byte) logical sectors, as the traditional } MAXPHYS value has for at least the past decade. } } We should be able to go safely up to 256 sectors. Anything larger requires } LBA48, which is not supported by some controllers. } } Do we know how a real ST506 or similar ancient drive would respond } to such a command? } } The ST506 was only a disk drive with no embedded controller logic. } So it wouldn't respond to such a command at all, as it doesn't even see it. } The command interface, after which the original ATA interface was modelled, } was that of the WD1010 disk controller, to which this and similar drives } would attach. You would tell the controller the cylinder/head/sector And, I very much doubt there were any PCI versions of these controllers since IDE came out well before the end of the ISA era. Worrying about drives that old is pretty much pointless. Even if you could find one, it is very likely to be non-functional (these weren't exactly high quality devices). }-- End of excerpt from Wolfgang Solfrank
Re: CVS commit: src/sys/dev/ata
On Oct 16, 2011, at 9:25 PM, John Nemeth wrote: On Feb 25, 1:28pm, Wolfgang Solfrank wrote: } Jonathan A. Kollasch schrieb: } On Wed, Oct 05, 2011 at 10:25:52AM +0200, Manuel Bouyer wrote: } On Wed, Oct 05, 2011 at 03:40:18AM +, Jonathan A. Kollasch wrote: } Module Name:src } Committed By: jakllsch } Date: Wed Oct 5 03:40:18 UTC 2011 } } Modified Files: } src/sys/dev/ata: wd.c } } Log Message: } Limit wd(4) transfers to 128 (512-byte) logical sectors, as the traditional } MAXPHYS value has for at least the past decade. } } We should be able to go safely up to 256 sectors. Anything larger requires } LBA48, which is not supported by some controllers. } } Do we know how a real ST506 or similar ancient drive would respond } to such a command? } } The ST506 was only a disk drive with no embedded controller logic. } So it wouldn't respond to such a command at all, as it doesn't even see it. } The command interface, after which the original ATA interface was modelled, } was that of the WD1010 disk controller, to which this and similar drives } would attach. You would tell the controller the cylinder/head/sector And, I very much doubt there were any PCI versions of these controllers since IDE came out well before the end of the ISA era. Worrying about drives that old is pretty much pointless. Even if you could find one, it is very likely to be non-functional (these weren't exactly high quality devices). You can still buy ESDI devices (that are compatible with the ST506 interface). Ebay has them from $35 to $535! Sizes up to 750MB. I was able to find ISA and Micro Channel ESDI cards. I didn't see EISA or PCI ones either on Ebay or Google... So I think you may be right about PCI. IIRC, the only machines that had these were 386 boxes that weren't lucky enough to have IDE (the frankenstein machines of the time, since by then multi-function cards with IDE were the common solution) and some of the 68k early home machines (Atari and Amiga maybe) and sun 3's. Warner
