Re: RELEASE discs ISO images (for future)
Hi Ken Smith!
On Wed, 12 Mar 2008 13:16:57 -0400; Ken Smith wrote about 'Re: RELEASE discs
ISO images (for future)':
I currently have no 7.0 ISOs to look at (and ftp.freebsd.org contains jus=
t
symlink to all available packages, not only disc1). But I remember perl,
linux and xorg on the disc1 from 6.2 times, yes. And actually the most ne=
eded
things are just perl and linux ABI, not heavy Xorg which can be moved to
disc2 - it=20
Disc1 contains all the packages necessary to get to the Would you like
to browse the pre-built packages menu in sysinstall without needing to
switch discs (which is desirable for novices as well as being able to
complete that portion, not bother selecting packages in the menu, and
thus not need disc2/disc3).
That's only list of them, not actual packages, right?
That includes xorg because it's one of the
things that can be chosen in the Software Distributions section. I'm
planning to change that with 8.0, no longer offering to have anything
that's not part of the baseline system installed until you get to the
Would you like to ... menu.
Good.
That will reinforce to people that that
stuff really is packages/ports and it will make things like the monthly
snapshots less of a hack (I don't include any packages on those so you
get odd results if you select All in the Software Distributions menu
for example...).
Also good.
But I didn't have a chance to get that stuff done for 7.0.
And what for 7.1 and 6.4 ?
The question is: What does the majority of users want?
=20
Attraction. Ability to say Wow! Their CD is SO handy, many
features on just one disk. Don't forget about advocacy and
opinionating new users.
In my opinion the above setup (being able to make any of the selections
we offer in the Distributions section and complete an install without
needing to switch discs {provided you opt out of selecting packages from
the packages menu}) is what benefits the most users.
Yes, but moving xorg to disc2 will help to reduce disk switching, isn't it?
I could be wrong
but this is one of those things that it's impossible to satisfy everyone
all the time so a decision needed to be made and that was it.
Sure, but we can tune it as much as we can. Ability to use disc1 for most needs
of both novice users and experienced corporate admins is good.
I *hope*
I can merge the livefs stuff back in to disc1 by eliminating Xorg from
the Distributions section (and the offer to install Linux as a
separate thing - let them select that from packages as well). But that
just wasn't possible for 7.0.
Umm, but isn't that hacky switch the thing which can reduce disk switching?
Such as, you are always installing Perl and Linux before packages, and when
you get to the packages menu, you don't need to insert disc2 first, install
something, then another which requires Perl and Linux as dependency, then
switch to disc1 to install them, then to disc2 to continue?
We'll see if it can happen for 8.0 (and
as pointed out in this thread the base system seems to continue to grow
so we'll see :-).
That's when geom_ugz can do it's job.
I've suggested above - just Xorg can be moved, perl and linux ABI are not
so big.
That causes even more disc shuffling pain than we have now. Disc1
currently contains both Gnome and KDE. Trying to move Xorg to disc1
means one of them needs to be moved to another disc, the three won't
fit.
Disc1 ? May be you've meant disc2 ?
And so many packages are intertwined among those three things the
disc switching becomes way worse. As things stand now if you select
All in the software distributions section everything from disc1 will
wind up being installed before you get to the Packages selection menu so
it will never ask for disc1 again.
Not tried it with 7.0, but 5.4 and 6.2 caused some switching.
If you then just select Gnome or KDE
disc2 goes in and it never asks for disc3. However if you select
anything more than Gnome or KDE things go downhill fast. But nowhere
near as fast as if all of either Gnome or KDE were not on disc1.
Yes, we need to make sysinstall smarter about the order it installs
stuff in. But I spent some time fiddling with the current layout given
what I had to work with as far as meta package sizes and ISO image sizes
go and this wound up being the least painful (note I don't claim
painless).
Yes, but KDE and Gnome and Xorg grow with time, too. So, even without this
changes, eventually all three will not fit to single disc2.
What I hope to shoot for with 8.0 is a CD-sized thing named disc1 that
is much like the monthly snapshots - no packages at all on it. If
possible at the point we're near 8.0's release given sizes livefs will
be merged back onto it. I'll have trimmed out the stuff sysinstall
offers to do before reaching the Would you like to browse pre-built
packages? menu so you don't get odd failures if you select
something-or-other and no pre-built packages are
Re: RELEASE discs ISO images (for future)
Hi Oliver Fromme! On Wed, 12 Mar 2008 18:49:53 +0100 (CET); Oliver Fromme wrote about 'Re: RELEASE discs ISO images (for future)': - Disk 1 contains everything you need to install the base FreeBSD system, as well as a few useful packages. Yes. Which? The most important ones, including the linux base package for the linux ABI, perl, xorg and a few other things. Just look at the /packages subdirectory for details. I currently have no 7.0 ISOs to look at (and ftp.freebsd.org contains just symlink to all available packages, not only disc1). But I remember perl, linux and xorg on the disc1 from 6.2 times, yes. And actually the most needed things are just perl and linux ABI, not heavy Xorg which can be moved to disc2 - it The xorg packages on disc1 occupy 54 MB. Not really all that much, I think. The linux base, perl and python occupy another 50 MB together. The rest are small utility things and dependencies (only a few MB). But that is still valuable if geom_ugz is in use. Also keep in mind that a new installer is in the works and will be usable really soon, as far as I know. I'm sure the authors are aware of the problem of installing packages from changeable media, and that there will be a better solution. This will surely not be finished before 8.0, and having improvements (even slight) in 7.1 and 6.4 is needed too. Until then, there are some workarounds for the problem. For example, you can copy all packages from the CDs to your harddisk and install from there. Not suitable for novice users. No, it's not difficult to do that. It's only a matter of documentation, I think. Users need to be made aware of the possibilities, they need to be made aware that they don't _have_ to install all the packages during system installation and play CD changer monkey. No. Novice user should be provided with less painful way. Making them to read docs before _and_ preparing space on hard drive is too disappointing. - The docs CD only contains documentation: Handbook, FAQ and articles in various languages. These are also available online, so there's rarely a need to download this CD. It's handy for novice users to have them in base system, though. I don't know ... I never used them. I think it's more convenient to read them online. Because it is not your first install :) Right, but I didn't read them either upon my first install 15 years ago. :-) The first thing I did when I received the Walnut Creek CDs was to go to www.freebsd.org and look for docs. Tempora mutantur. Users nowadays rarely go for docs in first place. They need understandable guide exactly in process. But if you do not have Internet yet, ability to look to Handbook directly from installer is VERY valuable. I guess almost everyone has internet access somehow (at home, at the office, at a friend, or elsewhere). No, that doesn't matter. If user have only one computer online with Internet, and during install previous operating system is of course unavailable, then Internet (and docs on www!) is also unavailable. So where would you browse the docs in the process except the installer itself and first disk? I'm not saying there should be no docs CD. In fact the docs CD is a very good thing. What I'm saying is that it doesn't have to be on the installation CD (disc1). And you _can_ view the docs from the installer. So I don't think there's a problem. Oh, HOW ? Is there something more than a little help provided by F1 in sysinstall? As you can see, disk1 + livefs is larger than 700 MB. The docs CD is separate anyway, which is a good thing because many people won't need it. And what about removing packages from disc1 ? The question is: What does the majority of users want? Attraction. Ability to say Wow! Their CD is SO handy, many features on just one disk. Don't forget about advocacy and opinionating new users. That's what the DVD is good for that you can buy (or you can easily make one yourself). On the DVD there is enough space for everything. Agreed, but CDs still will be an option for a long time. And care must be taken for those users who don't need packages and don't want to download DVD. It doesn't make sense to try to cram many things on a small CD and sacrificing usability and convenience for some or even many users. I think the current CD images are very usable and convenient, especially in the way they save download time and bandwidth. Not SO very :) Typically, many users only need to download disc1 and then install software from the ports collection, or install packages from the network. I think only very few users really need disk2 or disc3, or even the docs cd. Unfortunately the download numbers from the FTP servers don't say much, because many people blindly dowanload everything. You again forget about advocacy, new users coming from other OSes and possibly comparing with some Linux distros. Imagine a review like this:
a NIS problem
HI Today I setup a NIS server in Freebsd6.2. Now, every client only run ypbind -broadcast to link this server the NIS server's domainname is server.nis if the client run ypbind server.nis can't link to the server. anyone can tell me how to debug it? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Graphic boot loader?
Здравствуйте, . Does anybody know something about graphic boot loader? I mean how to make this? I know that some guy is did it, but how? That is the question! =) -- С уважением, Igor_Z mailto:[EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Graphic boot loader?
On Fri, Mar 14, 2008 at 10:19:39AM +0300, Igor_Z wrote: , . Does anybody know something about graphic boot loader? I mean how to make this? I know that some guy is did it, but how? That is the question! =) This is currently in development, as I understand it. The individual working on it is Oliver Fromme [EMAIL PROTECTED]. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A (perhaps silly) kqueue question
On 3/8/08, Vlad GALU [EMAIL PROTECTED] wrote:
On 3/8/08, Robert Watson [EMAIL PROTECTED] wrote:
On Fri, 7 Mar 2008, Vlad GALU wrote:
I see an unusual symptom with one of our in-house applications. The main
I/O
loop calls kevent(), which in turn returns two events with EV_EOF error
set,
always for the same descriptors (they're both socket descriptors). As
the
man page is not pretty clear about it and I don't have my UNP copy at
hand,
I would like to ask the list whether the error events are supposed to be
one-shot or not.
I wonder if it's returning one event for the read socket buffer, and one
event
for the write socket buffer, since there are really two event sources for
each
socket? Not that this is desirable behavior, but it might explain it.
If you
shutdown() only read, do you get back one EOF kevent and one writable
kevent?
I'll try that and see. The only issue being the low frequency this
symptom appears at. I'll get back to the list once I have more info.
Haven't gotten to the point of testing shutdown() behavior, but
here's a truss excerpt of the symptom:
-- cut here --
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
-- and here --
So two EOF are returrned for descriptor 7, and errno would be
ECONNRESET. The question is now, why isn't it oneshot?
Robert N M Watson
Computer Laboratory
University of Cambridge
--
Mahnahmahnah!
--
Mahnahmahnah!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A (perhaps silly) kqueue question
On 3/14/08, Vlad GALU [EMAIL PROTECTED] wrote:
On 3/8/08, Vlad GALU [EMAIL PROTECTED] wrote:
On 3/8/08, Robert Watson [EMAIL PROTECTED] wrote:
On Fri, 7 Mar 2008, Vlad GALU wrote:
I see an unusual symptom with one of our in-house applications. The
main I/O
loop calls kevent(), which in turn returns two events with EV_EOF
error set,
always for the same descriptors (they're both socket descriptors).
As the
man page is not pretty clear about it and I don't have my UNP copy
at hand,
I would like to ask the list whether the error events are supposed
to be
one-shot or not.
I wonder if it's returning one event for the read socket buffer, and
one event
for the write socket buffer, since there are really two event sources
for each
socket? Not that this is desirable behavior, but it might explain it.
If you
shutdown() only read, do you get back one EOF kevent and one writable
kevent?
I'll try that and see. The only issue being the low frequency this
symptom appears at. I'll get back to the list once I have more info.
Haven't gotten to the point of testing shutdown() behavior, but
here's a truss excerpt of the symptom:
-- cut here --
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
-- and here --
So two EOF are returrned for descriptor 7, and errno would be
ECONNRESET. The question is now, why isn't it oneshot?
Ah one more thing. When EOF is caught, a handler which forcibly
removes the event is called, but it keeps poping up again and again.
Robert N M Watson
Computer Laboratory
University of Cambridge
--
Mahnahmahnah!
--
Mahnahmahnah!
--
Mahnahmahnah!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A (perhaps silly) kqueue question
In the last episode (Mar 14), Vlad GALU said:
On 3/14/08, Vlad GALU [EMAIL PROTECTED] wrote:
On 3/8/08, Vlad GALU [EMAIL PROTECTED] wrote:
On 3/8/08, Robert Watson [EMAIL PROTECTED] wrote:
On Fri, 7 Mar 2008, Vlad GALU wrote:
I see an unusual symptom with one of our in-house
applications. The main I/O loop calls kevent(), which in turn
returns two events with EV_EOF error set, always for the same
descriptors (they're both socket descriptors). As the man
page is not pretty clear about it and I don't have my UNP
copy at hand, I would like to ask the list whether the error
events are supposed to be one-shot or not.
I wonder if it's returning one event for the read socket
buffer, and one event for the write socket buffer, since there
are really two event sources for each socket? Not that this
is desirable behavior, but it might explain it. If you
shutdown() only read, do you get back one EOF kevent and one
writable kevent?
I'll try that and see. The only issue being the low frequency
this symptom appears at. I'll get back to the list once I have
more info.
Haven't gotten to the point of testing shutdown() behavior, but
here's a truss excerpt of the symptom:
-- cut here --
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
-- and here --
So two EOF are returrned for descriptor 7, and errno would be
ECONNRESET. The question is now, why isn't it oneshot?
Ah one more thing. When EOF is caught, a handler which forcibly
removes the event is called, but it keeps poping up again and again.
Are you sure the event is being removed? I used to have a hack that
made the kernel return its current eventlist for a kqueue when you
called kevent() with nchanges set to -1 (handy for placing in a program
and using truss to print the result), but it has rotted. I'm attaching
it in case anyone wants to make it work again.
Since you got EOF status for both the read and write halves of the
socket, why not just close the fd? From my reading of the manpages,
unless you specified EV_ONESHOT when you added the event, events will
fire until you remove them or the condition that triggers them stops.
--
Dan Nelson
[EMAIL PROTECTED]
Index: kern_event.c
===
RCS file: /home/ncvs/src/sys/kern/kern_event.c,v
retrieving revision 1.113
diff -u -r1.113 kern_event.c
--- kern_event.c 14 Jul 2007 21:23:30 - 1.113
+++ kern_event.c 17 Jul 2007 18:10:47 -
@@ -659,6 +659,41 @@
nerrors = 0;
+#if 0 /* 1.92 broke this */
+ if (nchanges == -1) {
+ /* dump our eventlist into k_ops-arg */
+ int i;
+ int count = 0;
+ struct knote *kn;
+ error = 0;
+ KQ_LOCK(kq);
+
+ /* Walk our filedescriptor lists */
+ for (i = 0; i kq-kq_knlistsize count nevents; i++) {
+ SLIST_FOREACH(kn, kq-kq_knlist[i], kn_link) {
+copyout(kn-kn_kevent, (struct kevent)k_ops-arg[count], sizeof(kn-kn_kevent));
+count++;
+if (count = nevents)
+ break;
+ }
+ }
+
+ /* Walk our hash tables */
+ if (kq-kq_knhashmask != 0) {
+ for (i = 0; i = kq-kq_knhashmask count nevents; i++) {
+SLIST_FOREACH(kn, kq-kq_knhash[i], kn_link) {
+ copyout(kn-kn_kevent, (struct kevent)k_ops-arg[count], sizeof(kn-kn_kevent));
+ count++;
+ if (count = nevents)
+ break;
+}
+ }
+ }
+ KQ_UNLOCK(kq);
+ td-td_retval[0] = count;
+ goto done;
+ }
+#endif
while (nchanges 0) {
n = nchanges KQ_NEVENTS ? KQ_NEVENTS : nchanges;
error = k_ops-k_copyin(k_ops-arg, keva, n);
@@ -961,10 +996,12 @@
if ((kev-flags EV_DISABLE)
((kn-kn_status KN_DISABLED) == 0)) {
kn-kn_status |= KN_DISABLED;
+ kn-kn_kevent.flags |= EV_DISABLE;
}
if ((kev-flags EV_ENABLE) (kn-kn_status KN_DISABLED)) {
kn-kn_status = ~KN_DISABLED;
+ kn-kn_kevent.flags = ~EV_DISABLE;
if ((kn-kn_status KN_ACTIVE)
((kn-kn_status KN_QUEUED) == 0))
knote_enqueue(kn);
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A (perhaps silly) kqueue question
On 3/14/08, Dan Nelson [EMAIL PROTECTED] wrote:
In the last episode (Mar 14), Vlad GALU said:
On 3/14/08, Vlad GALU [EMAIL PROTECTED] wrote:
On 3/8/08, Vlad GALU [EMAIL PROTECTED] wrote:
On 3/8/08, Robert Watson [EMAIL PROTECTED] wrote:
On Fri, 7 Mar 2008, Vlad GALU wrote:
I see an unusual symptom with one of our in-house
applications. The main I/O loop calls kevent(), which in turn
returns two events with EV_EOF error set, always for the same
descriptors (they're both socket descriptors). As the man
page is not pretty clear about it and I don't have my UNP
copy at hand, I would like to ask the list whether the error
events are supposed to be one-shot or not.
I wonder if it's returning one event for the read socket
buffer, and one event for the write socket buffer, since there
are really two event sources for each socket? Not that this
is desirable behavior, but it might explain it. If you
shutdown() only read, do you get back one EOF kevent and one
writable kevent?
I'll try that and see. The only issue being the low frequency
this symptom appears at. I'll get back to the list once I have
more info.
Haven't gotten to the point of testing shutdown() behavior, but
here's a truss excerpt of the symptom:
-- cut here --
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
-- and here --
So two EOF are returrned for descriptor 7, and errno would be
ECONNRESET. The question is now, why isn't it oneshot?
Ah one more thing. When EOF is caught, a handler which forcibly
removes the event is called, but it keeps poping up again and again.
Are you sure the event is being removed? I used to have a hack that
made the kernel return its current eventlist for a kqueue when you
called kevent() with nchanges set to -1 (handy for placing in a program
and using truss to print the result), but it has rotted. I'm attaching
it in case anyone wants to make it work again.
Yep, I'm sure, I've just read the app logs again, we close the
descriptor in the connection destructor..
Since you got EOF status for both the read and write halves of the
socket, why not just close the fd? From my reading of the manpages,
unless you specified EV_ONESHOT when you added the event, events will
fire until you remove them or the condition that triggers them stops.
--
Dan Nelson
[EMAIL PROTECTED]
--
Mahnahmahnah!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Failure to Project OOImpress
Couldn't connect to projector for presentation. I was supposed to give a class presentation and we tried to hook my computer into the 15 pin female joint (sorry I forget what it is called three rows of 5 pins each on the computer, hooking to 15 pins on the wire) that I guess is usually a monitor connector. The professor kept saying hit function-f8 but that didn't go. I am running gnome on freeBSD [EMAIL PROTECTED] ~]$ uname -a FreeBSD kv_bsd 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 [EMAIL PROTECTED] ~]$ He said it was all about BIOS, but we were trying to hit func-f8 during gnome running, so I thought I would get a second opinion. Here is a link with pictures of the model decal: http://www.monkeyview.net/id/965/fsck/dmesg/index.vhtml *--* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *--* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
OpenBSD sdiff Question
Greetings- I am currently working on replacing the GNU version of sdiff with a version of sdiff that was released into the public domain and is used in OpenBSD Xin LI has been guiding me along with the project and he suggested I post here to see what you guys think. I achieve 100% compatability with the GNU version, I need to add -v/--version and the issue I ran into is that since this program would become part of the base os, what exactly should be displayed. My idea is to simply print __FreeBSD_version but I am open to other suggestions. For reference: $ sdiff -v sdiff (GNU diffutils) 2.8.7 Written by Thomas Lord. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. And my port from OpenBSD: $ ./sdiff -v sdiff (BSD diffutils) 602111 Written by Raymond Lai. This work has been released into the public domain. -- Steven Kreuzer http://www.exit2shell.com/~skreuzer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failure to Project OOImpress
Was it connected prior or after Xorg startup? On 3/14/08, KAYVEN RIESE [EMAIL PROTECTED] wrote: Couldn't connect to projector for presentation. I was supposed to give a class presentation and we tried to hook my computer into the 15 pin female joint (sorry I forget what it is called three rows of 5 pins each on the computer, hooking to 15 pins on the wire) that I guess is usually a monitor connector. The professor kept saying hit function-f8 but that didn't go. I am running gnome on freeBSD [EMAIL PROTECTED] ~]$ uname -a FreeBSD kv_bsd 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 [EMAIL PROTECTED] ~]$ He said it was all about BIOS, but we were trying to hit func-f8 during gnome running, so I thought I would get a second opinion. Here is a link with pictures of the model decal: http://www.monkeyview.net/id/965/fsck/dmesg/index.vhtml *--* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *--* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
