¶Ë±¸¸Û ¸Å´Ï¾Æ - ³ª´Â ¼½½º ÇÏ¸é¼ ¸ÞÀÏÀ» º¸³»Áö....
Title: Á¦¸ñ ¾øÀ½ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: adduser change: telling you when a group isn't there
On Sat, Feb 08, 2003, Giorgos Keramidas wrote: > It doesn't need to ( read as "should not" ) check for all the groups > involved, since when the group is the same as the username, it's > obvious that it will probably not exist. But if it already does, is > it an error? I think not, since one might want to create many users > who share the same group. > > What do you all think about the following patch then? [snip patch] I used pw to try and avoid directly hitting up file contents in case the admin has done something whacky in the nsswitch stakes. Everything else in adduser.sh uses pw AFAICT. Adrian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: finding changes from one release/patch level to another?
On 2003-02-07 17:21, Peter Pentchev <[EMAIL PROTECTED]> wrote: > On Fri, Feb 07, 2003 at 09:26:49AM -0500, Daniel Ellard wrote: > > Something slightly broke the em (gigabit ethernet) driver between > > 4.6.2p4 and 4.6.2p6, and I'm trying to figure what the change was so I > > can back it out on my machine. In 4.6.2p6 almost everything works, > > but programs that push the device (such as netperf) can hang. The > > same program running on other ethernet devices (fxp, xl) works fine. > > This happens on several machines, and they were all running correctly > > before I updated them, so I doubt that it is a hardware problem. > > > > I don't see any changes for the em driver source itself between p4 and > > p6, and the announced differences between these patch levels don't > > look related, but something must have changed. Is there a > > straightforward way to track down all the source code differences > > between p4 and p6 (or any arbitrary pair of patchlevels)? > > Since patchlevel bumps on the security branches are not accompanied by > CVS tagging, the only way I can think of would be a formail-like filter > on the messages in the commit logs, available in CVSROOT/commitlogs > after a CVSup of the CVS repository. The filter would have to parse the > multi-line commit messages, and look for a (branch: RELENG_4_6) token on > the Modified files: line. You can always use -D 'date1' -D 'date2' with cvs diff... For the relevant changes, I think the proper dates would be around revisions 1.44.2.23.2.21 -> -r1.44.2.23.2.23 of the file src/sys/conf/newvers.sh which yield the following date tags: % cvs diff -D '2002/10/26 21:00:00 UTC' -D '2003/01/06 12:45:00 UTC' Run this in /src and you'll find out all the changes. I have moved the dates slightly backward <-> forward, to catch commits that happened in a short timeframe around the change to newvers.sh - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: adduser change: telling you when a group isn't there
On 2003-02-07 16:10, Adrian Chadd <[EMAIL PROTECTED]> wrote:
> Hi,
> The adduser in -current doesn't check if a specified group exists
> until the call to pw right at the end. eep.
>
> My sh foo isn't terribly great, but this did it for me.
>
> Comments/rewrites are welcome. I'll commit the group consensus.
Hmmm, looking at it now, I see this part:
get_groups() {
ugroups="$defaultgroups"
_input=
_group=${ulogingroup:-"${username}"}
# ...
read _input
[ -n "$_input" ] && ugroups="$_input"
}
It doesn't need to ( read as "should not" ) check for all the groups
involved, since when the group is the same as the username, it's
obvious that it will probably not exist. But if it already does, is
it an error? I think not, since one might want to create many users
who share the same group.
What do you all think about the following patch then?
---8<--- cut here ---8<--- cut here ---8<--- cut here ---8<--- cut here ---
Index: adduser.sh
===
RCS file: /home/ncvs/src/usr.sbin/adduser/adduser.sh,v
retrieving revision 1.9
diff -u -r1.9 adduser.sh
--- adduser.sh 24 Jan 2003 02:05:51 - 1.9
+++ adduser.sh 8 Feb 2003 05:41:06 -
@@ -464,7 +464,12 @@
fi
read _input
- [ -n "$_input" ] && ugroups="$_input"
+ if [ -n "$_input" ] ; then
+ for tmpgroup in ${_input} ;do
+ grep -q "^${tmpgroup}:" /etc/group && \
+ ugroups="$_input"
+ fi
+ fi
}
# get_expire_dates
---8<--- cut here ---8<--- cut here ---8<--- cut here ---8<--- cut here ---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Help with understanding process state, context switching and
On Fri, Feb 07, 2003 at 03:35:15PM +0200, Andrey Simonenko wrote the words in effect of: > On Thu, Feb 06, 2003 at 10:50:28AM -0800, Julian Elischer wrote: > In this case, as I understand, I need to modify some parts of the kernel. > What is IP ? I think Julian meant IPI (Inter-Processor Interrupt), basically, a way of communicating with other CPUs in an x86 SMP system. They allow you to 'interrupt any other processor or set of processors' [1] -- This guide should give you a lot of valuable information regarding IPIs and basic SMP stuff. More details on SMP can be found in [2] for x86s. Cheers. [1] - IA-32 Intel(R) Architecture Software Developer's Manual Volume 3: System Programming Guide. Available from: http://developer.intel.com/ [2] - Intel(R) MultiProcessor Specification. Available from: http://developer.intel.com/ -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
¦¬¤J¼W¥[ªº¤èªk
Title: ¦L¶r¾÷ ·s¦~§ª«°e±z¤@¥x¦L¶r¾÷ ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
¦¬¤J¼W¥[ªº¤èªk
Title: ¦L¶r¾÷ ·s¦~§ª«°e±z¤@¥x¦L¶r¾÷ ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
HEADS UP: Broken if_dc NICs with MACs like 08:08[...] or 00:00[...]
Hi all,
Many if_dc cards are still broken in RELENG_4. Can you please
try this diff if you own such a broken card ?
If you have a Conexant LANfinity MiniPCI 10/100BaseTX card, I'd like
to have feedback if full duplex mode works now too.
Thank you very much for your tests. I'd like to see all these
DEC/Intel 21143 clone cards fixed for 4.8R.
Martin
-
http://people.freebsd.org/~mbr/patches/if_dc.c-MFC.diff
MFC Rev. 1.80, 1.81
Dynamically configure the width of the srom. This code comes from
OpenBSD who got the code (or the idea) from the NetBSD tlp driver.
MFC Rev. 1.67
Fix Conexant chips which always reports carrier lost
on full duplex mode.
Index: if_dc.c
===
RCS file: /home/ncvs/src/sys/pci/if_dc.c,v
retrieving revision 1.9.2.38
diff -u -r1.9.2.38 if_dc.c
--- if_dc.c 5 Feb 2003 22:10:04 - 1.9.2.38
+++ if_dc.c 7 Feb 2003 19:01:18 -
@@ -223,6 +223,7 @@
static void dc_eeprom_getword __P((struct dc_softc *, int, u_int16_t *));
static void dc_eeprom_getword_pnic
__P((struct dc_softc *, int, u_int16_t *));
+static void dc_eeprom_width__P((struct dc_softc *));
static void dc_read_eeprom __P((struct dc_softc *, caddr_t, int,
int, int));
@@ -250,6 +251,7 @@
static int dc_list_rx_init __P((struct dc_softc *));
static int dc_list_tx_init __P((struct dc_softc *));
+static void dc_read_srom __P((struct dc_softc *, int));
static void dc_parse_21143_srom__P((struct dc_softc *));
static void dc_decode_leaf_sia __P((struct dc_softc *,
struct dc_eblock_sia *));
@@ -324,6 +326,70 @@
CSR_READ_4(sc, DC_BUSCTL);
}
+static void dc_eeprom_width(sc)
+ struct dc_softc *sc;
+{
+ int i;
+
+ /* Force EEPROM to idle state. */
+ dc_eeprom_idle(sc);
+
+ /* Enter EEPROM access mode. */
+ CSR_WRITE_4(sc, DC_SIO, DC_SIO_EESEL);
+ dc_delay(sc);
+ DC_SETBIT(sc, DC_SIO, DC_SIO_ROMCTL_READ);
+ dc_delay(sc);
+ DC_CLRBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ DC_SETBIT(sc, DC_SIO, DC_SIO_EE_CS);
+ dc_delay(sc);
+
+ for (i = 3; i--;) {
+ if (6 & (1 << i))
+ DC_SETBIT(sc, DC_SIO, DC_SIO_EE_DATAIN);
+ else
+ DC_CLRBIT(sc, DC_SIO, DC_SIO_EE_DATAIN);
+ dc_delay(sc);
+ DC_SETBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ DC_CLRBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ }
+
+ for (i = 1; i <= 12; i++) {
+ DC_SETBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ if (!(CSR_READ_4(sc, DC_SIO) & DC_SIO_EE_DATAOUT)) {
+ DC_CLRBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ break;
+ }
+ DC_CLRBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ }
+
+ /* Turn off EEPROM access mode. */
+ dc_eeprom_idle(sc);
+
+ if (i < 4 || i > 12)
+ sc->dc_romwidth = 6;
+ else
+ sc->dc_romwidth = i;
+
+ /* Enter EEPROM access mode. */
+ CSR_WRITE_4(sc, DC_SIO, DC_SIO_EESEL);
+ dc_delay(sc);
+ DC_SETBIT(sc, DC_SIO, DC_SIO_ROMCTL_READ);
+ dc_delay(sc);
+ DC_CLRBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ DC_SETBIT(sc, DC_SIO, DC_SIO_EE_CS);
+ dc_delay(sc);
+
+ /* Turn off EEPROM access mode. */
+ dc_eeprom_idle(sc);
+}
+
static void dc_eeprom_idle(sc)
struct dc_softc *sc;
{
@@ -363,21 +429,24 @@
{
register intd, i;
- /*
-* The AN985 has a 93C66 EEPROM on it instead of
-* a 93C46. It uses a different bit sequence for
-* specifying the "read" opcode.
-*/
- if (DC_IS_CENTAUR(sc) || DC_IS_CONEXANT(sc))
- d = addr | (DC_EECMD_READ << 2);
- else
- d = addr | DC_EECMD_READ;
+ d = DC_EECMD_READ >> 6;
+ for (i = 3; i--; ) {
+ if (d & (1 << i))
+ DC_SETBIT(sc, DC_SIO, DC_SIO_EE_DATAIN);
+ else
+ DC_CLRBIT(sc, DC_SIO, DC_SIO_EE_DATAIN);
+ dc_delay(sc);
+ DC_SETBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ DC_CLRBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ }
/*
* Feed in each bit and strobe the clock.
*/
- for (i = 0x400; i; i >>= 1) {
- if (d & i) {
+ for (i = sc->dc_romwidth; i--;) {
+ if (addr & (1 << i)) {
SIO_SET(DC_SIO_EE_DATAIN);
Re: Resizing file-backed vnode disklabels
On Fri, Feb 07, 2003 at 01:30:52PM -0800, Hans Zaunere wrote: > > Fairly straight forward question I suppose. I'm creating several file-backed > vnode devices on a single physical disklabel to support some jails. If I > start the file at 1gb is it possible to increase the file without losing the > data within it? Would growfs be safe to use? Could I be so bold as to just > tack on 100mb of null chars at the end of the file (I would doubt it, > although it'd be nice). That's doable. You have to re-write the disklabel to correspond to the new size of the backing store, and you need to make sure the fsize, bsize and bps/cpg fields in the disklabel are set to reasonable values in order for growfs(8) to do it's thing. http://www.freebsd.org/cgi/getmsg.cgi?fetch=403393+411791+/usr/local/www/db/text/2002/freebsd-questions/20021006.freebsd-questions Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Resizing file-backed vnode disklabels
Fairly straight forward question I suppose. I'm creating several file-backed vnode devices on a single physical disklabel to support some jails. If I start the file at 1gb is it possible to increase the file without losing the data within it? Would growfs be safe to use? Could I be so bold as to just tack on 100mb of null chars at the end of the file (I would doubt it, although it'd be nice). My goal, is to be able to deliver jails, based on a filesystem that can resize easily. The physical disk is 80gb so I have the room; it's just a matter of delegating it in an easily manageable manner. So far, using vnodes seem to be my best bet, although I'd like to hear other ideas that people have come up with. Thanks, Hans To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Îïèñàíèå - FREEBSD-HACKERS
Title: Ó âàñ íåò çàêàçîâ Ó âàñ íåò çàêàçîâ? Ïåðåñòàëè çâîíèòü êëèåíòû? Î Âàøèõ óñëóãàõ íèêòî íå çíàåò? Íå õâàòàåò äåíåã íà ïðîâåäåíèå øèðîêîìàñøòàáíîé ðåêëàìû? Âñå ýòè ïðîáëåìû ìû ñìîæåì ðåøèòü âñåãî çà 300$. Çà ýòè äåíüãè ó Âàñ ïîÿâèòüñÿ âîçìîæíîñòü ðàçîñëàòü ñâîå ñîîáùåíèå íà 3.800.000 ïîëó÷àòåëåé! Òîëüêî âäóìàéòåñü â ýòó öèôðó! Ðàññûëêà äëèòüñÿ â òå÷åíèè 1 äíÿ.  áàçó E-Mail àäðåñîâ ïîïàëè íå òîëüêî îðãàíèçàöèè è ïðåäïðèÿòèÿ Ìîñêâû è Ðîññèè, íî è âñå ÷àñòíûå ëèöà. Âñÿ áàçà íà 100% âåðèôèöèðîâàííàÿ è ìû äàåì ãàðàíòèþ íà å¸ êà÷åñòâî! ÏËÞÑ! Çàêàçàâ ó íàñ E-Mail ðàññûëêó ñåé÷àñ, Âû ñìîæåòå âîñïîëüçîâàòüñÿ íàøåé íàêîïèòåëüíîé ñèñòåìîé (ïîäðîáíîñòè ïðè çàêàçå). Çàêàçàòü ðàññûëêó Âû ñìîæåòå çäåñü.×òîáû óäàëèòü ñâîé E-Mail, íàæìèòå çäåñü.(ñ) 2003 DEMETRIUS Software. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Making pkg_XXX tools smarter about file types...
I have yet another suggestion regarding packaging subsystem -- could it be possible to extend pkg_* functionality (and, in fact, ports functionality) to recognize modest set of wildcards in dependencies names? It seems pretty unreasonable to have various subrevisions of, say, libiconv, pulled as packages dependencies ending with libiconv-1.7_5, libiconv-1.8, libiconv-1.8_1 and installed. And still another package would complain about having no -1.8_2. I'd like to see in dependencies not only like "was built with -1.9_2abc, so wants it", but also something like -1.5+ (obviously 1.5.0 and newer), -* (any version will do). Perhaps something else. At least to have possibility of specifying that, if this can't go into official ports. Does it seem reasonable? Tim Kientzle wrote: The attached patch modifies the pkg_install tools to inspect the file contents--rather than the [...] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: finding changes from one release/patch level to another?
On Fri, 7 Feb 2003, Jacques A. Vidrine wrote: > > Something slightly broke the em (gigabit ethernet) driver between > > 4.6.2p4 and 4.6.2p6, and I'm trying to figure what the change was so I > > can back it out on my machine. ... > > It seems awfully unlikely that the changes between 4.6.2p4 and 4.6.2p6 > have anything to do with your problem. I think you are probably barking > up the wrong tree. I agree that it seems unlikely, based on the apparent differences, but I don't have a better theory right now. Everything worked under 4.6.2 base install (from the ISO on the freebsd site), and everything continued to work under 4.6.2p2 and 4.6.2p4 (upgraded by doing a cvsup, make world, make buildkernel, etc). I updated two machines to 4.6.2p6 a few weeks ago, and things started to break. (I updated almost all my machines, but only the machines with the intel em cards have the problems, and only on the network connections that use the em cards.) I rebuilt netperf and netserver after each update. Since the em cards are all attached to the same network switch, my first suspicion was the switch. I tried a different switch, and even (just to be complete) tried a 100Mb switch and even a 10Mb hub, but this did not solve the problem. Yesterday I backed out two of the em machines, bringing their kernels back to 4.6.2p0 (and doing a buildkernel for my local config), and the problem went away again. So whether the problem is related to the kernel code, or some part of the update process, it looks to me like it's something that happens along the way from 4.6.2p4 and 4.6.2p6. > > Is there a straightforward way to track down all the source code > > differences between p4 and p6 (or any arbitrary pair of > > patchlevels)? > > Check out the RELENG_4_6 branch. Then run e.g. > > cvs -q diff -j 'RELENG_4_6:2002/10/28' -j 'RELENG_4_6:2003/01/08' > > Output attached to save you the trouble. I'll take a look at it. Thanks, -Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: finding changes from one release/patch level to another?
On Fri, Feb 07, 2003 at 09:36:58AM -0600, Jacques A. Vidrine wrote: > On Fri, Feb 07, 2003 at 09:26:49AM -0500, Daniel Ellard wrote: > > > > Something slightly broke the em (gigabit ethernet) driver between > > 4.6.2p4 and 4.6.2p6, and I'm trying to figure what the change was so I > > can back it out on my machine. In 4.6.2p6 almost everything works, > > but programs that push the device (such as netperf) can hang. The > > same program running on other ethernet devices (fxp, xl) works fine. > > This happens on several machines, and they were all running correctly > > before I updated them, so I doubt that it is a hardware problem. > > > > I don't see any changes for the em driver source itself between p4 and > > p6, and the announced differences between these patch levels don't > > look related, but something must have changed. > > It seems awfully unlikely that the changes between 4.6.2p4 and 4.6.2p6 > have anything to do with your problem. I think you are probably barking > up the wrong tree. > > > Is there a > > straightforward way to track down all the source code differences > > between p4 and p6 (or any arbitrary pair of patchlevels)? > > Check out the RELENG_4_6 branch. Then run e.g. > > cvs -q diff -j 'RELENG_4_6:2002/10/28' -j 'RELENG_4_6:2003/01/08' Argh.. this is "the third, obvious solution" that I missed in my other mail :) The fact that the branches are not tagged does not prevent a cvs diff, of course it doesn't! G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. msg39684/pgp0.pgp Description: PGP signature
Re: finding changes from one release/patch level to another?
On Fri, Feb 07, 2003 at 09:26:49AM -0500, Daniel Ellard wrote: > > Something slightly broke the em (gigabit ethernet) driver between > 4.6.2p4 and 4.6.2p6, and I'm trying to figure what the change was so I > can back it out on my machine. In 4.6.2p6 almost everything works, > but programs that push the device (such as netperf) can hang. The > same program running on other ethernet devices (fxp, xl) works fine. > This happens on several machines, and they were all running correctly > before I updated them, so I doubt that it is a hardware problem. > > I don't see any changes for the em driver source itself between p4 and > p6, and the announced differences between these patch levels don't > look related, but something must have changed. Is there a > straightforward way to track down all the source code differences > between p4 and p6 (or any arbitrary pair of patchlevels)? Since patchlevel bumps on the security branches are not accompanied by CVS tagging, the only way I can think of would be a formail-like filter on the messages in the commit logs, available in CVSROOT/commitlogs after a CVSup of the CVS repository. The filter would have to parse the multi-line commit messages, and look for a (branch: RELENG_4_6) token on the Modified files: line. You might have to make several passes, seeing as the commit logs are separated by category; start with a pass over 'sys' to establish the dates of the newvers.sh patchlevel bumps (you could do that part by hand), then run through all the other logs to isolate commits within that time interval. Not trivial, but not too hard - sounds like 20 minutes of Perl scripting... unfortunately, those are 20 minutes that I do not have right now to offer you a prototype :( I wonder.. I wonder if it might be easier to run the commit logs through another filter first, which would format them as e-mail messages, or just grab the cvs-all list archives, then use something similar to procmail's formail(1) to work on that. The cvs-all archives would have the advantage of the X-CVS-Branch: header, so parsing is limited to a run through grep -q before processing. That *might* indeed be easier... Of course, there could be a third, obvious solution, that we are both missing :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Do you think anybody has ever had *precisely this thought* before? msg39683/pgp0.pgp Description: PGP signature
Re: finding changes from one release/patch level to another?
On Fri, Feb 07, 2003 at 09:26:49AM -0500, Daniel Ellard wrote: > > Something slightly broke the em (gigabit ethernet) driver between > 4.6.2p4 and 4.6.2p6, and I'm trying to figure what the change was so I > can back it out on my machine. In 4.6.2p6 almost everything works, > but programs that push the device (such as netperf) can hang. The > same program running on other ethernet devices (fxp, xl) works fine. > This happens on several machines, and they were all running correctly > before I updated them, so I doubt that it is a hardware problem. > > I don't see any changes for the em driver source itself between p4 and > p6, and the announced differences between these patch levels don't > look related, but something must have changed. It seems awfully unlikely that the changes between 4.6.2p4 and 4.6.2p6 have anything to do with your problem. I think you are probably barking up the wrong tree. > Is there a > straightforward way to track down all the source code differences > between p4 and p6 (or any arbitrary pair of patchlevels)? Check out the RELENG_4_6 branch. Then run e.g. cvs -q diff -j 'RELENG_4_6:2002/10/28' -j 'RELENG_4_6:2003/01/08' Output attached to save you the trouble. Cheers, -- Jacques A. Vidrine <[EMAIL PROTECTED]> http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] Index: UPDATING === RCS file: /home/ncvs/src/UPDATING,v retrieving revision 1.73.2.68.2.30 retrieving revision 1.73.2.68.2.32 diff -c -r1.73.2.68.2.30 -r1.73.2.68.2.32 *** UPDATING26 Oct 2002 21:11:30 - 1.73.2.68.2.30 --- UPDATING6 Jan 2003 12:38:21 - 1.73.2.68.2.32 *** *** 17,29 updates that don't have an advisory, or to be safe, you can do a full build and install as described in the COMMON ITEMS section. ! 20021026: p4 smrsh bypass bug. ! 20021023: p3 Correct kadmind buffer overflow. ! 20020911: p2 The kvm_openfiles/kvm_open functions now mark the returned file descriptors close-on-exec in case set-user-ID/set-group-ID applications are careless. --- 17,35 updates that don't have an advisory, or to be safe, you can do a full build and install as described in the COMMON ITEMS section. ! 20030106: p6 FreeBSD-SA-02:44.filedesc ! Correct a reference counting bug in fpathconf(2). ! ! 20021113: p5 FreeBSD-SA-02:43.bind ! Correct name server vulnerabilities. ! ! 20021026: p4 FreeBSD-SA-02:41.smrsh smrsh bypass bug. ! 20021023: p3 FreeBSD-SA-02:40.kadmind Correct kadmind buffer overflow. ! 20020911: p2 FreeBSD-SA-02:39.libkvm The kvm_openfiles/kvm_open functions now mark the returned file descriptors close-on-exec in case set-user-ID/set-group-ID applications are careless. *** *** 1191,1194 If you find this document useful, and you want to, you may buy the author a beer. ! $FreeBSD: src/UPDATING,v 1.73.2.68.2.30 2002/10/26 21:11:30 gshapiro Exp $ --- 1197,1200 If you find this document useful, and you want to, you may buy the author a beer. ! $FreeBSD: src/UPDATING,v 1.73.2.68.2.32 2003/01/06 12:38:21 nectar Exp $ Index: contrib/bind/CHANGES === RCS file: /home/ncvs/src/contrib/bind/CHANGES,v retrieving revision 1.1.1.7.2.6.2.1 retrieving revision 1.1.1.7.2.6.2.2 diff -c -r1.1.1.7.2.6.2.1 -r1.1.1.7.2.6.2.2 *** contrib/bind/CHANGES15 Jul 2002 07:51:02 - 1.1.1.7.2.6.2.1 --- contrib/bind/CHANGES14 Nov 2002 03:18:40 - 1.1.1.7.2.6.2.2 *** *** 1,3 --- 1,23 + 1469. [bug] buffer length calculation for PX was wrong. + + 1468. [bug] ns_name_ntol() could overwite a zero length buffer. + + 1467. [bug] off by one bug in ns_makecannon(). + + 1466. [bug] large ENDS UDP buffer size could trigger a assertion. + + 1465. [bug] possible NULL pointer dereference in db_sec.c + + 1464. [bug] the buffer used to construct the -ve record was not + big enough for all possible SOA records. use pointer + arithmetic to calculate the remaining size in this + buffer. + + 1463. [bug] use serial space arithmetic to determine if a SIG is + too old, in the future or has internally constistant + times. + + 1462. [bug] write buffer overflow in make_rr(). --- 8.3.3-REL released --- (Wed Jun 26 21:15:43 PDT 2002) Index: contrib/bind/bin/named/db_defs.h === RCS file: /home/ncvs/src/contrib/bind/bin/named/db_defs.h,v retri
finding changes from one release/patch level to another?
Something slightly broke the em (gigabit ethernet) driver between 4.6.2p4 and 4.6.2p6, and I'm trying to figure what the change was so I can back it out on my machine. In 4.6.2p6 almost everything works, but programs that push the device (such as netperf) can hang. The same program running on other ethernet devices (fxp, xl) works fine. This happens on several machines, and they were all running correctly before I updated them, so I doubt that it is a hardware problem. I don't see any changes for the em driver source itself between p4 and p6, and the announced differences between these patch levels don't look related, but something must have changed. Is there a straightforward way to track down all the source code differences between p4 and p6 (or any arbitrary pair of patchlevels)? Thanks, -Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Help with understanding process state, context switching and
On Thu, Feb 06, 2003 at 10:50:28AM -0800, Julian Elischer wrote: > > The only way it makes sense to talk about suspending > a process in user space from the kernel, would be in a MP system. in a > UP system, if you are in the kernel, then there is no process in user > space. (it trapped into the kernel whenever whatever interrupt that > stasrted you running happenned). In other words: on UP system it is possible to remove a process from the run queue and then this process can be considered as "suspended", because current syscall can't be preempted, and PCB of suspended process is valid (that is the kernel saved it). Is this correct? > In SMP you may need to set some flag > and send an IP to all teh processes to ensure that the process enters > the kernel to see the flag. In this case, as I understand, I need to modify some parts of the kernel. What is IP ? > Depending on what you wnat to do, it is > possible that ptrace (as DES says) is what you want, or maybe just a > SIGSTOP will do. > I will think about ptrace(2) and about SIGSTOP again (the problem with SIGSTOP I described in previous letter: signal will be delivered to a target process asynchronously with respect to the current process and I need to stay in a loop in a syscall and check when a SIGSTOP signal will be delivered to a process). I would like somebody to comment other questions in my previous latter, probably this will help me. Thanks Julian and DES for your help! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
adduser change: telling you when a group isn't there
Hi,
The adduser in -current doesn't check if a specified group exists until
the call to pw right at the end. eep.
My sh foo isn't terribly great, but this did it for me.
Comments/rewrites are welcome. I'll commit the group consensus.
Adrian
diff:
--- /usr/src/usr.sbin/adduser/adduser.shFri Jan 24 02:05:51 2003
+++ adduser.sh Fri Feb 7 08:04:15 2003
@@ -47,6 +47,16 @@
fi
}
+# Check whether the given group exists
+check_group() {
+ ${PWCMD} show group $1 1> /dev/null 2> /dev/null
+ if [ "$?" = "0" ]; then
+ echo "1"
+ return
+ fi
+ echo "0"
+}
+
# get_nextuid
# Output the value of $_uid if it is available for use. If it
# is not, output the value of the next higher uid that is available.
@@ -570,8 +580,31 @@
get_user
get_gecos
get_uid
- get_logingroup
- get_groups
+ ok="NO"
+
+ # The code creates a group = $user if one doesn't exist.
+ # We are just going to capture other non-existant groups!
+ while [ "$ok" = "NO" ] ; do
+ ok="YES"
+ get_logingroup
+ if [ "$ulogingroup" != "" -a "$username" != "$ulogingroup" -a
+"`check_group $ulogingroup`" = "0" ]; then
+ echo "Group $ulogingroup does not exist!"
+ ok="NO"
+ fi
+ done
+
+ ok="NO"
+ while [ "$ok" = "NO" ] ; do
+ ok="YES"
+ get_groups
+ for i in $ugroups; do
+ if [ "$username" != "$i" -a "`check_group $i`" = "0" ]; then
+ echo "Group $i does not exist!"
+ ok="NO"
+ fi
+ done
+ done
+
get_class
get_shell
get_homedir
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
