Re: Junior Kernel hacker task: Floppy driver mode handling.

[Alexey Klimov]

On Wed, 12 Dec 2001, Poul-Henning Kamp wrote:

> In message <[EMAIL PROTECTED]>, Warner Losh writes:
> >In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
> >: 6.  Add the "rx50" entry from above to the table to show how simple
> >: that is now.
> >
> >But rx50 also needs some extra processing to handle the software
> >interleave.
> 
> I know.
> 
> That doesn't change the fact that our floppy density code needs a
> rewrite.
Hi,

I have patch for reading/writing DEC RX50 floppy for old 
2.2.7-RELEASE, which I made severel years ago. 
I found two problems then. The first is interliave, and
the second is that the first logical track is mapped
to the last physical.
I may look through my archives, port this patch to CURRNET 
and send it to you.

Alexey Klimov

> 
> -- 
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Junior Kernel hacker task: Floppy driver mode handling.

[Warner Losh]

In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: >: 6.  Add the "rx50" entry from above to the table to show how simple
: >: that is now.
: >
: >But rx50 also needs some extra processing to handle the software
: >interleave.
: 
: I know.
: 
: That doesn't change the fact that our floppy density code needs a
: rewrite.

No it doesn't.  Just wanted whoever was doing it to know...

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Greg Lehey]

On Tuesday, 11 December 2001 at 19:42:30 -0800, Terry Lambert wrote:
> Greg Lehey wrote:
>> Of course.  But you're missing the point: ufs is *not* a port, it has
>> been with BSD since the beginning.  There is a similar list of items
>> for JFS which would need to be addressed, with the additional issue of
>> the fact that it was not designed for FreeBSD.
>
> I maintain that the FreeBSD UFS *is* a port of the Heidemann
> implementation from the FICUS project, which had to be done because
> certain files were claimed to be "contaminated" with USL IP, and
> were removed as part of the USL/UCB settlement (6 key files from 5
> subsystems, which they thought we couldn't rewrite from scratch in
> time to be a competitive threat).

Which files?  Did they require adapting to a different environment?

> I also maintain that the most difficult thing is getting the list of
> items, and, with the information from the UFS work in hand, the JFS
> specific items not on that list are trivial (there are exactly two
> items, in fact: log roll forward/backward, and transaction abort).

I'd expect these to be the easiest parts, since they don't have too
much to do with the rest of the system.  One of the issues with Linux
is that the interface to the rest of the system, and I don't expect
these parts to have much interfacing to do.

>>> I think that everyone saying "Ut oh!  SCARY!" gives people the wrong
>>> idea, and scares off potential contributors in these areas.
>>
>> I'm not saying that.  I'm saying that it's non-trivial, which I
>> suppose is what you mean when you say "where are the patches?".  As I
>> said, I'm quite happy to help people port JFS2 to FreeBSD.
>
> I ported the entire GFS user space tools set, sans two, to FreeBSD in
> about 2 hours. 

I expect the user space tools for JFS2 to be pretty straightforward
too.

>> If we port JFS2, it will be relatively trivial to have it as the root
>> file system too.
>
> Only, you will never be able to build a firewall, router, or other
> product that ships with it statically linked into the kernel, since
> that would violate the terms of the GPL (additional restrictions,
> and linked code not being GPL'ed).

Fine, so we load the module.  What's your point?

> What good is the damn thing, if the only people who can use it are
> ...

Well, I suppose it'll still be good for them.  Maybe.

> RMS has indicated a willingness to sue people distributing bipartite
> distributions, where the linking is delayed until installation to
> work around the letter of the GPL.  Given his religious convictions,
> I can't see him *not*.  Factor that into your decision.

You want me personally to get him to agree that loading modules at
boot time does not violate the GPL?

Greg
--
See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Junior Kernel hacker task: Floppy driver mode handling.

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
>: 6.  Add the "rx50" entry from above to the table to show how simple
>: that is now.
>
>But rx50 also needs some extra processing to handle the software
>interleave.

I know.

That doesn't change the fact that our floppy density code needs a
rewrite.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Craig R]

I think I would rather see people tweaking the heck out of the existing UFS 
filesystem and implementing new ways of getting it to go faster. 
Implementing a whole new filesystem would probably take a lot of work, and 
the performance wouldn't be much better anyways. IMHO, people interested in 
making a filesystem faster should stick with UFS. FreeBSD should not do what 
Linux does, which is make a whole bunch of different filesystems that all 
suck in a different way.

This is an opinion and should be taken as such, not an insult to those that 
like the whole JFS idea.

-Craig

_
Chat with friends online, try MSN Messenger: http://messenger.msn.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Junior Kernel hacker task: Floppy driver mode handling.

[Warner Losh]

In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: 6.  Add the "rx50" entry from above to the table to show how simple
: that is now.

But rx50 also needs some extra processing to handle the software
interleave.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: irq

[Warner Losh]

In message <[EMAIL PROTECTED]> Terry Lambert writes:
: Some cards do not have a hardware "I caused an interrupt" register,
: and use a differential (e.g. ring head vs. tail inequal after
: interrupt) to tell if there is work to do.  If these cards were to
: share interrupts, then they most likely do work every interrupt,
: and less work per interrupt, then would otherwise be the case (i.e.
: it would defeat hardware interrupt coelescing thresholds, among
: other things).

No such PCI cards can exists.  The PCI spec requires that interrupt
sharing work.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: irq

[Warner Losh]

In message <[EMAIL PROTECTED]> Danny Braniss writes:
: Q: are all interrupt handlers for the shared irq called, or only the
:'correct' one?

You can't tell which card really interrupted.  All of them are called.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Terry Lambert]

Greg Lehey wrote:
> Of course.  But you're missing the point: ufs is *not* a port, it has
> been with BSD since the beginning.  There is a similar list of items
> for JFS which would need to be addressed, with the additional issue of
> the fact that it was not designed for FreeBSD.

I maintain that the FreeBSD UFS *is* a port of the Heidemann
implementation from the FICUS project, which had to be done because
certain files were claimed to be "contaminated" with USL IP, and
were removed as part of the USL/UCB settlement (6 key files from 5
subsystems, which they thought we couldn't rewrite from scratch in
time to be a competitive threat).

I also maintain that the most difficult thing is getting the list
of items, and, with the information from the UFS work in hand, the
JFS specific items not on that list are trivial (there are exactly
two items, in fact: log roll forward/backward, and transaction
abort).


> > I think that everyone saying "Ut oh!  SCARY!" gives people the wrong
> > idea, and scares off potential contributors in these areas.
> 
> I'm not saying that.  I'm saying that it's non-trivial, which I
> suppose is what you mean when you say "where are the patches?".  As I
> said, I'm quite happy to help people port JFS2 to FreeBSD.

I ported the entire GFS user space tools set, sans two, to FreeBSD in
about 2 hours.  If FreeBSD had the necessary hardware drivers for
shared disks, I would have finished the two that I didn't do, and then
I would have gone to Frys, bought the necessary controllers, disk, and
two scratch boxes, and finished porting the whole damn thing.  I think
I could have it all up and running in about 4 weeks, assuming the Linux
implementation actually works for more than one machine, and my test
machines were configured dual boot for Linux/FreeBSD.  Unlike IBM, the
GFS people have indicated a willingness to bend on the license issue.

When I say "trivial", I mean "trivial", as the term is used in physics
or mathematics: a well understood operation that can be performed rote,
and does not require significant original thinking to perform.

When I say "where are the patches?" I mean "that's an incredibly
stupid idea, given the license, and you aren't going to get me to do
that work without paying me, so you might as well send patches -- do
the work yourself -- because you are going to have a hell of a time
getting buy-in from anyone clued enough to do the work for you".


> If we port JFS2, it will be relatively trivial to have it as the root
> file system too.

Only, you will never be able to build a firewall, router, or other
product that ships with it statically linked into the kernel, since
that would violate the terms of the GPL (additional restrictions,
and linked code not being GPL'ed).

What good is the damn thing, if the only people who can use it are
big site admins who build their own kernels, and never expect to
sell their company to anyone (or are prepared to recompile all the
kernels on all their machines, should the company ever sell, since
they can't transfer ownership of a FreeBSD kernel with GPL'ed code
in it directly, without violating the license)?

RMS has indicated a willingness to sue people distributing bipartite
distributions, where the linking is delayed until installation to
work around the letter of the GPL.  Given his religious convictions,
I can't see him *not*.  Factor that into your decision.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Greg Lehey]

On Tuesday, 11 December 2001 at  1:08:23 -0800, Terry Lambert wrote:
> Greg Lehey wrote:
>>> FS porting to FreeBSD is actually pretty trivial(*), though some
>>> transactioning changes to the FreeBSD VFS layer consumers (the
>>> system calls and NFS server code) would be necessary to make
>>> the journal roll-back function correctly, following a failure.
>>>
>>> (*) Trivial: meaning grunt work is required; not necessarily an
>>> indicator of the amount of work, only the intellectual effort
>>> required for the job
>>
>> Considering that the current UFS implementation didn't need to be
>> ported, and people are still working on the details, I think that this
>> is a highly misleading statement.
>
> The current UFS has a number of issues which make it non-trivial;
> it was, in effect, a port; here is the short list:
>
> 
>
> Live code always has issues, particularly if you are trying to
> pound a round peg into a square hole (hence Kirk taking up the
> task of a redesign).

Of course.  But you're missing the point: ufs is *not* a port, it has
been with BSD since the beginning.  There is a similar list of items
for JFS which would need to be addressed, with the additional issue of
the fact that it was not designed for FreeBSD.

> I think that everyone saying "Ut oh!  SCARY!" gives people the wrong
> idea, and scares off potential contributors in these areas.

I'm not saying that.  I'm saying that it's non-trivial, which I
suppose is what you mean when you say "where are the patches?".  As I
said, I'm quite happy to help people port JFS2 to FreeBSD.

On Tuesday, 11 December 2001 at  2:26:45 -0800, Hiten Pandya wrote:
>> [... Hiten want's to GPL'ify FreeBSD ...]
>
> hi,
> first of all, i would like to clear of some point which have been
> taken wrongly.
>
> o  My Intentions were never to GPL'ify FreeBSD :-)

Agreed, I don't think anybody thought that.

> o  The reason i started this discussion was because
>i think JFS/JFS2 would be a nice addition to
>FreeBSD like the rest of the other filesystems.
>
> o  The JFS does _not_ have to be root, and even if
>people were to download it because it is GPL'ed,
>the size of the filesystem is only around 1.0MB

If we port JFS2, it will be relatively trivial to have it as the root
file system too.

> o  It is hard to Port AIX or OS/2 based code, but we
>have to agree that, BSD Users were meant to take
>that kind of challenges, have taken before

It's probably easier to port AIX based code than OS/2 or Linux based
code.

Greg
--
See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Tangent for discussion: FreeBSD performs worse that Linux

[D J Hawkey Jr]

On Dec 11, at 08:17 PM, Paul Chvostek wrote:
> 
> I currently have the domains mybsd.(com|net|org|biz).  If you'd
> like the patch database to be associated with any or all of those
> domains, I'd be happy to oblige.  (The hostname "patch.mybsd.com"
> is pretty. ;> )

Indeed. Quite clever. I'll consider this, and get back to you.

> On Tue, Dec 11, 2001 at 05:48:19AM -0600, D J Hawkey Jr wrote:
> >
> > Ack. Don't do that. Sooner or later, the economy will pick up again, I'll
> > get myself the badly-needed job I lost, and my play-time will once again
> > be reduced by a factor of four. The last thing I'll need then is any kind
> > of publicity.
> 
> Ah, but with fame can come fortune.  Once you're widely known as The Man
> for customizing FreeBSD, you can double your consulting rates, thereby
> doubling the free time you can allocate to the library.  ;-)

Heh. I'll consider this, too.

> p

Thanks,
Dave

-- 
  __ __
  \__   \D. J. HAWKEY JR.   /   __/
 \/\ [EMAIL PROTECTED]/\/
  http://www.visi.com/~hawkeyd/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Tangent for discussion: FreeBSD performs worse that Linux

[Paul Chvostek]

On Tue, Dec 11, 2001 at 05:48:19AM -0600, D J Hawkey Jr wrote:
>
> No challenge necessary. I, too, believe the general attitude is "Go for it.".
> So I'm going to. It won't be much to look at initially - maybe ever - but
> I'll bring it up and see what happens. It'll take a few days, but I'll post
> an "It's here." when it's here. BTW, am I allowed to use the daemon mascot?

I currently have the domains mybsd.(com|net|org|biz).  If you'd
like the patch database to be associated with any or all of those
domains, I'd be happy to oblige.  (The hostname "patch.mybsd.com"
is pretty. ;> )

I've been trying to figure out what to do with these for quite a
while.  Perhaps this is an opportunity.

> Ack. Don't do that. Sooner or later, the economy will pick up again, I'll
> get myself the badly-needed job I lost, and my play-time will once again
> be reduced by a factor of four. The last thing I'll need then is any kind
> of publicity.

Ah, but with fame can come fortune.  Once you're widely known as The Man
for customizing FreeBSD, you can double your consulting rates, thereby
doubling the free time you can allocate to the library.  ;-)

p


-- 
  Paul Chvostek <[EMAIL PROTECTED]>
  Operations / Development / Abuse / Whatever   vox: +1 416 598-
  IT Canadahttp://www.it.ca/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Junior Kernel hacker task: Floppy driver mode handling.

[Kenneth Wayne Culver]

I was thinking about looking into it, but I won't have time to start until
the 18th. if you wanna do it, go for it, and I'll wait my turn for the
next thing I can do in the kernel. :-D

Ken

On Tue, 11 Dec 2001, Andrew R. Reiter wrote:

> 
> Someone already doing this?  If not, I'm down.
> 
> On Tue, 11 Dec 2001, Poul-Henning Kamp wrote:
> 
> :
> :There exists a patch for adding a mode to our floppy driver to
> :add DEC RX50 media handling.
> :
> :The crucial part of this is the addition of this line:
> :{ 10,2,0xFF,0x10,80, 800,1,FDC_300KBPS,1,0x2E,1 }, /*  400K DEC RX50 */
> :
> :But if one examines the fd.c driver, one cannot help but notice that the
> :handling of densities is a bit convoluted, to put it mildly.
> :
> :I'm looking for a volounteer to do this, it is a quite simple job and
> :I am quite sure that practically everybody has the hardware they need to
> :do this :-)
> :
> :Cleaning it up consists of the following steps:
> :
> :1.  Define a new set of (bitmap) macros to distinguish the drive type:
> : #define FD_3S   0x0001  /* 3.5" single density */
> : #define FD_5S   0x0002  /* 5.25" single density */
> : ...
> :And use these instead of the FD_1200 and similar in 
> :struct fd_data->type.
> :
> :2.  Augment the struct fd_type with two new fields:
> : int minor;  /* minor device encoding */
> : int drives; /* bitmap of compatible drives (FD_[35][SD]) */
> :And fill these fields out in the fd_types[NUMTYPES] array.
> :Add a termination entry at the end of the table so the
> :NUMTYPES, NUMDENS, and FD_%d[5_25] #defines can be eliminated.
> :
> :3.  Change the _clone code to use the new "minor" field instead of
> :the private table it uses now.  (Eliminate and avoid any
> :use of NUMTYPES, NUMDENS and FD_%d[5_25]).
> :
> :4.  Change the code in Fdopen to examine the "drives" field in the
> :fd_types[] array instead of the hardcoded switch.  (Eliminate
> :and avoid any use of NUMTYPES, NUMDENS and and FD_%d[5_25]);
> :
> :5.  Remove any other use of NUMTYPES, NUMDENS and FD_%d[5_25]
> :
> :6.  Add the "rx50" entry from above to the table to show how simple
> :that is now.
> :
> :7.  Make it possible to define a new mode from userland with an ioctl.
> :(hint: instead of the index, put a pointer to the struct fd_type into
> :the fd_data structure.)
> :
> :Preferably, send one patch per step rather than one huge patch since that
> :will make reviewing easier.
> :
> :First volounteer to send me email gets the assignment.
> :
> :-- 
> :Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> :[EMAIL PROTECTED] | TCP/IP since RFC 956
> :FreeBSD committer   | BSD since 4.3-tahoe
> :Never attribute to malice what can adequately be explained by incompetence.
> :
> :To Unsubscribe: send mail to [EMAIL PROTECTED]
> :with "unsubscribe freebsd-hackers" in the body of the message
> :
> 
> --
> Andrew R. Reiter
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Josef Karthauser]

On Tue, Dec 11, 2001 at 07:58:04PM +, Wayne Pascoe wrote:
> Josef Karthauser <[EMAIL PROTECTED]> writes:
> 
> > It is probably a one man job if that man knows the kernel inside
> > and out in these areas, and has the time and energy to see it
> > through.  I'd suggest that you find a much much smaller area to
> > work on yourself for now though.  (Take a look in the PR database
> > for ideas of where to start).
> 
> What is the PR database of which you speak and where can I find it? I
> am looking for a project to work on in my free time. 

http://www.freebsd.org/support.html#gnats

Joe



msg29979/pgp0.pgp
Description: PGP signature

Re: Tangent for discussion: FreeBSD performs worse that Linux

[D J Hawkey Jr]

On Dec 11, at 05:52 PM, Michael Lucas wrote:
> 
> > OK, I'll take the addy (what's the convention, initials? Mine are "djhjr").
> > The freebsd.org mailserver is POP3able, right?
> 
> Sorry, I've misspoke here:
> 
> A lot of people volunteer to do this sort of thing, and never really
> carry it through.  This sadly happens often enough that we don't give
> out the email addresses until there's actual stuff that gets out
> there, maintained for a while, and integrated into the project.  My
> sincere apologies for implying anything else.
> 
> [SNIP]

Hey, it's OK. I understand. Don't sweat it.

> Michael Lucas

Dave

-- 
  __ __
  \__   \D. J. HAWKEY JR.   /   __/
 \/\ [EMAIL PROTECTED]/\/
  http://www.visi.com/~hawkeyd/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Tangent for discussion: FreeBSD performs worse that Linux

[Michael Lucas]

On Tue, Dec 11, 2001 at 03:54:44PM -0600, D J Hawkey Jr wrote:
> On Dec 11, at 04:23 PM, Michael Lucas wrote:
> NOW what'd I get myself into? The wife is gonna kill me.

Well, yes.

> > Nope.  Just an @freebsd.org mail addy and a coupon for economy-size
> > Maalox.  Sorry.  Put up what you've got.
> 
> OK, I'll take the addy (what's the convention, initials? Mine are "djhjr").
> The freebsd.org mailserver is POP3able, right?

Sorry, I've misspoke here:

A lot of people volunteer to do this sort of thing, and never really
carry it through.  This sadly happens often enough that we don't give
out the email addresses until there's actual stuff that gets out
there, maintained for a while, and integrated into the project.  My
sincere apologies for implying anything else.

(The following is in no way about you in particular, Hawk; it's just
an unfair characterization we're stuck with, because it seems to fit
the facts.) Unfortunately, many people start things and never finish
them, or don't see them through.  Since @freebsd.org is one of the few
things we have to offer committers, we don't hand them out to people
who are starting things.  (If more people actually carried through,
I'm sure this would change.)

I started doing things is 1999, but got a commit bit last month.
Admittedly, most of those didn't go directly into the project.  Yours,
I suspect, will get picked up quickly if you can coordinate it well.

> You don't mind if a few others weight in, do you? I can spell, but I'd like
> opinion on the language vis-a-vis the targetted audience. And some legal
> kinda guy or girl. I don't know if the disclaimer is adequate protection.

Seriously, it's your project.  Involve as many people as you want.
You are in change.  (That's the hardest thing to get used to with this
project.)


-- 
Michael Lucas
[EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.blackhelicopters.org/~mwlucas/
Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Invitation for seminar. Ïðèãëàøåíèå íà ñåìèíàð

[csc_seminar]

Ïðåäñòàâèòåëüñòâî Êîìïàíèè Capital Standard Corporation ïðèãëàøàåò Âàñ ïðèíÿòü 
ó÷àñòèå â îäíîäíåâíûõ êîíñóëüòàöèîííûõ ñåìèíàðàõ-ïðàêòèêóìàõ äëÿ ýôôåêòèâíîãî è 
áûñòðîãî ïîâûøåíèÿ êâàëèôèêàöèè ñîòðóäíèêîâ Âàøåé êîìïàíèè

 
Îäíîäíåâíûé êîíñóëüòàöèîííûé ñåìèíàð-ïðàêòèêóì «Áèðæåâàÿ òîðãîâëÿ íà ìåæäóíàðîäíûõ 
ôèíàíñîâûõ ðûíêàõ. Ïðàêòè÷åñêèå àñïåêòû»
Äàòà ïðîâåäåíèÿ: 19 äåêàáðÿ 2001 ãîäà
Âðåìÿ ïðîâåäåíèÿ ñåìèíàðà: 9.30-17.30
Ìåñòî ïðîâåäåíèÿ: Èíñòèòóò ìåæäóíàðîäíûõ îòíîøåíèé
 ïðîãðàììå ñåìèíàðà:
1. Ñïåêóëÿöèè - êàê ñïîñîá ïðèóìíîæåíèÿ êàïèòàëà:
- ×àñòíûå èíâåñòîðû
- Êîðïîðàòèâíûå è äðóãèå ó÷àñòíèêè ðûíêà
- Ñóììà, äîñòàòî÷íàÿ äëÿ ðàáîòû
2. Èíñòðóìåíòû ìèðîâûõ òîâàðíûõ è ôèíàíñîâûõ ðûíêîâ:
- FOREX - ìåæäóíàðîäíûé ðûíîê îáìåíà âàëþò
- Ôüþ÷åðñíûå è îïöèîííûå êîíòðàêòû 
3. Òåõíîëîãèÿ è ìåõàíèçì áèðæåâûõ è âíåáèðæåâûõ îïåðàöèé: 
- Çàêîíîäàòåëüíàÿ áàçà, ïðàâèëà è ïðàêòèêà àìåðèêàíñêîé ìîäåëè òîðãîâëè
- Âàëþòíûé ðûíîê «spot»
- Áèðæåâûå òîðãîâûå ñèñòåìû
- Êîìïüþòåðíûå òîðãîâûå ñèñòåìû
- Èíôîðìàöèîííûå ñèñòåìû è êîìïüþòåðíûå òåõíîëîãèè ïî îáåñïå÷åíèþ äèëèíãîâûõ 
îïåðàöèé 
4. Êàê «äîòÿíóòüñÿ» äî ðûíêà:
- Áðîêåðñêàÿ êîìïàíèÿ
- Ïðèíöèïàë (ìàðêåò-ìåéêåð)
- Òîðãîâûé ñ÷¸ò
- Ìàðæà
- Êðåäèòíîå ïëå÷î
- Ñîâåðøåíèå ñäåëêè
- Ïëþñû è ìèíóñû "èíòåðíåò-òîðãîâëè"
- Ïðèáûëüíîñòü îïåðàöèé 
5. Ïðîãíîçèðîâàíèå ðûíî÷íûõ òåíäåíöèé:
- Òåõíè÷åñêèé àíàëèç
- Ôóíäàìåíòàëüíûé àíàëèç
- Ïðîôåññèîíàëüíûå êîìïüþòåðíûå ñèñòåìû è ïðîãðàììíîå îáåñïå÷åíèå, 
èñïîëüçóåìîå â ðàáîòå äèëåðîâ

Ñòîèìîñòü ó÷àñòèÿ â ñåìèíàðå: 440 ãðèâåí
Äëÿ âòîðîãî è òðåòüåãî ó÷àñòíèêà îò îäíîé êîìïàíèè ñêèäêà – 10%.
 ñòîèìîñòü âêëþ÷åíû: îáó÷åíèå è êîíñóëüòàöèè íà ñåìèíàðå, îáåä, êîôå-áðåéêè. 
Ýêñêëþçèâíûé àëüáîì ìàòåðèàëîâ «Áèðæåâàÿ òîðãîâëÿ íà ìåæäóíàðîäíûõ ôèíàíñîâûõ ðûíêàõ. 
Ïðàêòè÷åñêèå àñïåêòû», ïîäãîòîâëåííîãî ýêñïåðòàìè ñïåöèàëüíî äëÿ ó÷àñòíèêîâ ñ ó÷¸òîì 
âñåõ ïîñëåäíèõ èçìåíåíèé è äîïîëíåíèé.


Îäíîäíåâíûé êîíñóëüòàöèîííûé ñåìèíàð-ïðàêòèêóì:
«Òàìîæåííîå ðåãóëèðîâàíèå âíåøíåýêîíîìè÷åñêîé äåÿòåëüíîñòè»
Äàòà ïðîâåäåíèÿ: 21 äåêàáðÿ 2001 ãîäà
Âðåìÿ ïðîâåäåíèÿ ñåìèíàðà: 9.30-17.30
Ìåñòî ïðîâåäåíèÿ: Êîíôåðåíö-çàë ãîñòèíèöû «Ñàíêò-Ïåòåðáóðã»
 ïðîãðàììå ñåìèíàðà:
Îñîáåííîñòè òàìîæåííîãî çàêîíîäàòåëüñòâà â ñôåðå âíåøíåýêîíîìè÷åñêîé äåÿòåëüíîñòè.
Çàêîí Óêðàèíû «Î Òàìîæåííîì òàðèôå Óêðàèíû» îò 5.04.2001 ¹ 2371-²²². Èçìåíåíèÿ è 
äîïîëíåíèÿ â Çàêîí Óêðàèíû ïî ñîñòîÿíèþ íà 1.12.01. Óêðàèíñêàÿ òîâàðíàÿ íîìåíêëàòóðà 
âíåøíåýêîíîìè÷åñêîé äåÿòåëüíîñòè. 
Îñîáåííîñòè òàìîæåííîãî îôîðìëåíèÿ â ðàìêàõ ñîãëàøåíèé î ñâîáîäíîé òîðãîâëå. 
Ïåðñïåêòèâà ðàçâèòèÿ çîíû ñâîáîäíîé òîðãîâëè.
Íîâûå ïðàâèëà ñòðàíû ïðîèñõîæäåíèÿ òîâàðîâ. Ïîðÿäîê ïðèìåíåíèÿ ñåðòèôèêàòîâ  CT-1, 
EUR 1,2.
Âîïðîñû êëàññèôèêàöèè òîâàðîâ. Îáçîð íîðìàòèâíûõ äîêóìåíòîâ ÃÒÑÓ ïî âîïðîñàì 
òàðèôíîãî ðåãóëèðîâàíèÿ ïî ñîñòîÿíèþ íà 1.12.01.
Îñîáåííîñòè çàïîëíåíèÿ ÃÒÄ ïðè ðàçëè÷íûõ òàìîæåííûõ ðåæèìàõ. Ëèçèíãîâûå êîíòðàêòû, 
âðåìåííûé ââîç òîâàðà.
Îôîðìëåíèå ÃÒÄ ïî âíåøíåýêîíîìè÷åñêèì äîãîâîðàì ñ ó÷àñòèåì áîëåå äâóõ ñòîðîí.
Êðèòåðèè îïðåäåëåíèÿ òàìîæåííûìè îðãàíàìè Óêðàèíû «ãðóïï ðèñêà» 
(âíåøíåýêîíîìè÷åñêèå îïåðàöèè, êîòîðûå òðåáóþò äåòàëüíîé ïðîâåðêè íà çàêîííîñòü 
ñäåëêè). Óñòàíîâëåíèå ôàêòîâ òàìîæåííûõ ïðàâîíàðóøåíèé, êëàññèôèêàöèÿ è ïðîöåññóàëüíîå 
îôîðìëåíèå ôàêòîâ ïðàâîíàðóøåíèé, ñàíêöèè, ïðåäóñìîòðåííûå çàêîíîäàòåëüñòâîì, 
ïîñëåäñòâèÿ âîçìîæíûå äëÿ ñóáúåêòîâ ÂÝÄ.
Ïðàâîâûå îñíîâû äëÿ îñóùåñòâëåíèÿ ìåæäóíàðîäíîé àäìèíèñòðàòèâíîé ïîìîùè â 
òàìîæåííûõ çîíàõ (ó÷àñòèå Óêðàèíû â ìåæäóíàðîäíûõ êîíâåíöèÿõ ïî òàìîæåííûì âîïðîñàì, 
äâóõ- è ìíîãîñòîðîííèå ìåæãîñóäàðñòâåííûå äîãîâîðà).
Ïîðÿäîê ðåàëèçàöèè êîíâåíöèé, ñîãëàøåíèé, î âçàèìíîé àäìèíèñòðàòèâíîé ïîìîùè â 
òàìîæåííûõ âîïðîñàõ.

Ñòîèìîñòü ó÷àñòèÿ â ñåìèíàðå 570 ãðèâåí
Äëÿ âòîðîãî è òðåòüåãî ó÷àñòíèêà îò îäíîé ôèðìû ñêèäêà – 10%.
 ñòîèìîñòü âêëþ÷åíû: îáó÷åíèå è êîíñóëüòàöèè íà ñåìèíàðå, îáåä, êîôå-áðåéêè. 
Ýêñêëþçèâíûé àëüáîì ìàòåðèàëîâ «Òàìîæåííîå ðåãóëèðîâàíèå âíåøíåýêîíîìè÷åñêîé 
äåÿòåëüíîñòè», ïîäãîòîâëåííîãî ýêñïåðòàìè ñïåöèàëüíî äëÿ ó÷àñòíèêîâ ñ ó÷¸òîì âñåõ 
ïîñëåäíèõ èçìåíåíèé è äîïîëíåíèé
 
Íàøà êîìïàíèÿ ïðåäëàãàåò òàêóþ óñëóãó êàê ïðîâåäåíèå èíäèâèäóàëüíûõ 
êîíñóëüòàöèîííûõ ñåìèíàðîâ ïî âûáðàííîé Âàìè òåìàòèêå ó Âàñ â îôèñå.
Äëÿ ó÷àñòèÿ â ñåìèíàðå íåîáõîäèìî çàðåãèñòðèðîâàòüñÿ ïî íàøèì òåëåôîíàì è 
ïîäòâåðäèòü ñâîå ó÷àñòèå îïëàòîé 
(044) 494 46 58,  E-mail: [EMAIL PROTECTED]


Ìû ïðèíîñèì ñâîè èçâèíåíèÿ, åñëè ïîäîáíàÿ ðàññûëêà Âàì íå èíòåðåñíà. Óäàëèòü ñâîé 
àäðåñ èç ñïèñêà ïîäïèñ÷èêîâ Âû ìîæåòå, îòîñëàâ ïèñüìî ïî àäðåñó 
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Tangent for discussion: FreeBSD performs worse that Linux

[Mike Meyer]

D J Hawkey Jr <[EMAIL PROTECTED]> types:
> On Dec 11, at 04:23 PM, Michael Lucas wrote:
> > On Tue, Dec 11, 2001 at 03:04:59PM -0600, D J Hawkey Jr wrote:
> > > I am rather hoping there's a bunch of packrats lurking in hacker@ that might
> > > mail me their backports. It'd make a better initial impression.
> > 
> > Let me disabuse you of that notion right now.  You're it.  Most people
> > in -hackers fall into two groups:
> > 
> > 1) track -stable
> > 2) track -current
> 
> You're kidding. A whole bunch of folk, all dedicated to an OS, and nobody's
> got patch archives?? *Sheesh*

You can find my patch archives at http://www.FreeBSD.org/cgi/query-pr-summary.cgi > :-)

Basically, I submit patches as prs. Those that I consider really
important I'll keep around until the PR gets dealt with. I've as yet
to have something that was both important enough for me to keep
separately and closed without being added to the base code.

Why keep it myself when I can get it added to the base system?

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Tangent for discussion: FreeBSD performs worse that Linux

[D J Hawkey Jr]

On Dec 11, at 04:23 PM, Michael Lucas wrote:
> 
> On Tue, Dec 11, 2001 at 03:04:59PM -0600, D J Hawkey Jr wrote:
> > I am rather hoping there's a bunch of packrats lurking in hacker@ that might
> > mail me their backports. It'd make a better initial impression.
> 
> Let me disabuse you of that notion right now.  You're it.  Most people
> in -hackers fall into two groups:
> 
> 1) track -stable
> 2) track -current

You're kidding. A whole bunch of folk, all dedicated to an OS, and nobody's
got patch archives?? *Sheesh*

NOW what'd I get myself into? The wife is gonna kill me.

> You're it.  Congrats.  Put up what you've got.
> 
> > Only if I get BSD daemon badges for my machines, a BSD sweatshirt or cap,
> > and an "@freebsd.org" mail addy. :-)
> 
> Nope.  Just an @freebsd.org mail addy and a coupon for economy-size
> Maalox.  Sorry.  Put up what you've got.

OK, I'll take the addy (what's the convention, initials? Mine are "djhjr").
The freebsd.org mailserver is POP3able, right?

But I'll swap the coupons for daemon PC badges. I don't do over-the-counter
drugs. All right, all right. A twelve-pack of Guiness. In cans; the bottled
stuff is too flat.

> 
> 
> Good start, now let's get some patches up there.  :)

That'll be the time-consuming part. Not the posting of 'em, but describing
'em. I want that part to be as concise as possible.

You don't mind if a few others weight in, do you? I can spell, but I'd like
opinion on the language vis-a-vis the targetted audience. And some legal
kinda guy or girl. I don't know if the disclaimer is adequate protection.

> Michael Lucas

Dave

-- 
  __ __
  \__   \D. J. HAWKEY JR.   /   __/
 \/\ [EMAIL PROTECTED]/\/
  http://www.visi.com/~hawkeyd/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Tangent for discussion: FreeBSD performs worse that Linux

[Michael Lucas]

On Tue, Dec 11, 2001 at 03:04:59PM -0600, D J Hawkey Jr wrote:
> I am rather hoping there's a bunch of packrats lurking in hacker@ that might
> mail me their backports. It'd make a better initial impression.

Let me disabuse you of that notion right now.  You're it.  Most people
in -hackers fall into two groups:

1) track -stable
2) track -current

You're it.  Congrats.  Put up what you've got.

> Only if I get BSD daemon badges for my machines, a BSD sweatshirt or cap,
> and an "@freebsd.org" mail addy. :-)

Nope.  Just an @freebsd.org mail addy and a coupon for economy-size
Maalox.  Sorry.  Put up what you've got.

> For those that're interested (and have the time), it's at
> http://www.visi.com/~hawkeyd/freebsd-backports.html
> for review/critique. It's only a WIP at this point; please don't do anything
> to publicize it. I'll mail hackers@ again when it's done, for final review/
> critique.

Oh.  Well, okay, you put up what you got.



Good start, now let's get some patches up there.  :)

-- 
Michael Lucas
[EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.blackhelicopters.org/~mwlucas/
Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Tangent for discussion: FreeBSD performs worse that Linux

[D J Hawkey Jr]

On Dec 11, at 07:14 PM, Nik Clayton wrote:
> 
> I meant that any effort you put in is better than none.  For example, if
> you decide to start producing patches for 4.4 that bring in some
> features from -stable (e.g., delayed acks) that's far better than you
> not doing it at all.

As others have also said. Yup.

> Don't feel that because you can't do everything you want to do that you
> shouldn't do any of it.  If you get the ball rolling, and become known
> as *the* place to go for extra patches, you'll find that other people 
> start sending you additional patches to include.

Oh, no. I don't have a problem with starting small. I wasn't born 6'0",
after all.

I am rather hoping there's a bunch of packrats lurking in hacker@ that might
mail me their backports. It'd make a better initial impression.

I don't have any pretentions or aspirations of being "the place to go" for
backports. If it happens, it happens.

> Pretty soon we'll get bored of having people ask "Hey, why aren't these
> patches in RELENG_4_4" (or whatever) and we'll corral you in to becoming
> a committer so that you can make this an 'official' part of FreeBSD.

Only if I get BSD daemon badges for my machines, a BSD sweatshirt or cap,
and an "@freebsd.org" mail addy.  :-)

> > > > So far, I've made three patchfiles that can be applied to 4.2REL and 4.3REL.
> > > > Not exactly the repertoire one would need to garner interest and momentum.
> > > 
> > > It's a start.  What's the URL?
> > 
> > You're kidding, right? I only started thinking about doing this yesterday!
> > The patches are sitting right here, in $(HOME)/projects.
> 
> OK.  Well, if you put them up on a web site, we can link to them.  If
> you can think of appropriate other places on the FreeBSD web site to
> mention them then we can do that too.

The page is half-built now. If freebsd.org wants to link to the page (or
any other BSD sites, for that matter) that's OK with me. Linking to the
individual patchfiles pro'lly isn't a good idea.

For those that're interested (and have the time), it's at
http://www.visi.com/~hawkeyd/freebsd-backports.html
for review/critique. It's only a WIP at this point; please don't do anything
to publicize it. I'll mail hackers@ again when it's done, for final review/
critique.

> N

Let the flaming begin!
Dave

-- 
  __ __
  \__   \D. J. HAWKEY JR.   /   __/
 \/\ [EMAIL PROTECTED]/\/
  http://www.visi.com/~hawkeyd/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: random + large IRQ's + SMP

[Mark Murray]

> What I need to know is when this was fixed (assuming it was).  I
> tried to look through i386/i386/mem.c, per the messages to find
> the fix, but somewhere between when that message was posted and
> now random (and a few other things) were ripped out of there and
> scattered across several machine independant files.

This has not been fixed. I could look at it (I am the author of that)
and look for a solution. It may take a bit of time.

> with "unsubscribe freebsd-hackers" in the body of the message
-- 
o   Mark Murray
\_  FreeBSD Services Limited
O.\_Warning: this .sig is umop ap!sdn

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: statefulness in character device drivers

[Warner Losh]

In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: In message <[EMAIL PROTECTED]>, Dave R
: ufino writes:
: 
: >> Most likely he means a per-open(2) opaque datum that is kept in
: >> struct file and passed to the underlying routines.
: >
: >Sorry, unbelievably bad at explaining myself. Per-open data is what i
: >meant. The reason I'm interested is it would make a full nvidia driver
: >port quite a bit easier.
: 
: Sorry, I know of no current plans which adress this.
: 
: The issue is non-trivial to fix because we currently don't pass
: dup(2) events through the vnode layer.

I'm using a cloning device driver for my needs in this area.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Tangent for discussion: FreeBSD performs worse that Linux

[Nik Clayton]

On Mon, Dec 10, 2001 at 03:24:14PM -0600, D J Hawkey Jr wrote:
> > Doesn't mean that you need 100% coverage though.  If you produce
> > something that only gets in 80% of the patches that could be applied
> > back that's still better than what we have now.  And it makes it easier
> > for someone else to help out with the missing 20%.
> 
> Huh? You completely list me with this. Are you trying to say that some
> feature of a patch that applies to just the last three of four prior
> releases is OK, 'cuz right now none are (except for security fixes to
> RELENG_(current - 1))?

I meant that any effort you put in is better than none.  For example, if
you decide to start producing patches for 4.4 that bring in some
features from -stable (e.g., delayed acks) that's far better than you
not doing it at all.

Don't feel that because you can't do everything you want to do that you
shouldn't do any of it.  If you get the ball rolling, and become known
as *the* place to go for extra patches, you'll find that other people 
start sending you additional patches to include.

Pretty soon we'll get bored of having people ask "Hey, why aren't these
patches in RELENG_4_4" (or whatever) and we'll corral you in to becoming
a committer so that you can make this an 'official' part of FreeBSD.

> > > So far, I've made three patchfiles that can be applied to 4.2REL and 4.3REL.
> > > Not exactly the repertoire one would need to garner interest and momentum.
> > 
> > It's a start.  What's the URL?
> 
> You're kidding, right? I only started thinking about doing this yesterday!
> The patches are sitting right here, in $(HOME)/projects.

OK.  Well, if you put them up on a web site, we can link to them.  If
you can think of appropriate other places on the FreeBSD web site to
mention them then we can do that too.

Don't be put off because you want to start small. . .

N
-- 
FreeBSD: The Power to Serve http://www.freebsd.org/
FreeBSD Documentation Project   http://www.freebsd.org/docproj/

  --- 15B8 3FFC DDB4 34B0 AA5F  94B7 93A8 0764 2C37 E375 ---



msg29969/pgp0.pgp
Description: PGP signature

Re: system halt

[Chris Dillon]

On Tue, 11 Dec 2001, Dmitry Mottl wrote:

> This is from /var/run/dmesg.boot
> ==
> sio0: configured irq 4 not in bitmap of probed irqs 0
> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
> sio0: type 8250
> ==
>
> When I write
> cu -l /dev/cuaa0
>
> system halts (console/network is not working at all)
>
> What happens?
> How can I aid this?

You have the serial port disabled in the BIOS, or not set to the I/O
port and IRQ that FreeBSD is expecting.  Enable it in the BIOS and
make sure the BIOS and FreeBSD agree about the settings by changing
one or the other.  I'm not sure exactly why this causes FreeBSD to
freeze, but I have come across the problem as well.  It is definately
a hardware problem with an unfortunate software side-effect.


--
 Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED]
 FreeBSD: The fastest and most stable server OS on the planet
 - Available for IA32 (Intel x86) and Alpha architectures
 - IA64, PowerPC, UltraSPARC, and ARM architectures under development
 - http://www.freebsd.org



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Wayne Pascoe]

Josef Karthauser <[EMAIL PROTECTED]> writes:

> It is probably a one man job if that man knows the kernel inside
> and out in these areas, and has the time and energy to see it
> through.  I'd suggest that you find a much much smaller area to
> work on yourself for now though.  (Take a look in the PR database
> for ideas of where to start).

What is the PR database of which you speak and where can I find it? I
am looking for a project to work on in my free time. 

Thanks,

-- 
- Wayne Pascoe
 | The thing is, I was POSITIVE that I 
[EMAIL PROTECTED]  | wasn't actually depressed, just that life 
http://www.molemanarmy.com   | had no meaning and I was tired of living.
 | -- daystar on k5
 | 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Josef Karthauser]

On Tue, Dec 11, 2001 at 04:01:04AM -0800, Hiten Pandya wrote:
> 
> but thats only if three of more people are _really_
> interested in porting it... cause as you know...
> porting an IBM file system (from looks) is not a 
> one man job :-)
> 

It is probably a one man job if that man knows the kernel inside
and out in these areas, and has the time and energy to see it
through.  I'd suggest that you find a much much smaller area to
work on yourself for now though.  (Take a look in the PR database
for ideas of where to start).

Joe



msg29966/pgp0.pgp
Description: PGP signature

system halt

[Dmitry Mottl]

Hi

I have problem accessing cuaa0


This is from /var/run/dmesg.boot
==
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 8250
==

When I write
cu -l /dev/cuaa0

system halts (console/network is not working at all)

What happens?
How can I aid this?

ps.
FreeBSD-4.0
My kernel uses same sio0 configuration as GENERIC:
device  sio0at isa? port IO_COM1 flags 0x10 irq 4


Thank You!

--
Dmitry mottl


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Junior Kernel hacker task: Floppy driver mode handling.

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, "And
rew R. Reiter" writes:
>
>Someone already doing this?  If not, I'm down.

You won, you're the first one in my inbox :-)

Ready ?

Steady ?

Start!

:-)

>
>On Tue, 11 Dec 2001, Poul-Henning Kamp wrote:
>
>:
>:There exists a patch for adding a mode to our floppy driver to
>:add DEC RX50 media handling.
>:
>:The crucial part of this is the addition of this line:
>:{ 10,2,0xFF,0x10,80, 800,1,FDC_300KBPS,1,0x2E,1 }, /*  400K DEC RX50 */
>:
>:But if one examines the fd.c driver, one cannot help but notice that the
>:handling of densities is a bit convoluted, to put it mildly.
>:
>:I'm looking for a volounteer to do this, it is a quite simple job and
>:I am quite sure that practically everybody has the hardware they need to
>:do this :-)
>:
>:Cleaning it up consists of the following steps:
>:
>:1.  Define a new set of (bitmap) macros to distinguish the drive type:
>:  #define FD_3S   0x0001  /* 3.5" single density */
>:  #define FD_5S   0x0002  /* 5.25" single density */
>:  ...
>:And use these instead of the FD_1200 and similar in 
>:struct fd_data->type.
>:
>:2.  Augment the struct fd_type with two new fields:
>:  int minor;  /* minor device encoding */
>:  int drives; /* bitmap of compatible drives (FD_[35][SD]) */
>:And fill these fields out in the fd_types[NUMTYPES] array.
>:Add a termination entry at the end of the table so the
>:NUMTYPES, NUMDENS, and FD_%d[5_25] #defines can be eliminated.
>:
>:3.  Change the _clone code to use the new "minor" field instead of
>:the private table it uses now.  (Eliminate and avoid any
>:use of NUMTYPES, NUMDENS and FD_%d[5_25]).
>:
>:4.  Change the code in Fdopen to examine the "drives" field in the
>:fd_types[] array instead of the hardcoded switch.  (Eliminate
>:and avoid any use of NUMTYPES, NUMDENS and and FD_%d[5_25]);
>:
>:5.  Remove any other use of NUMTYPES, NUMDENS and FD_%d[5_25]
>:
>:6.  Add the "rx50" entry from above to the table to show how simple
>:that is now.
>:
>:7.  Make it possible to define a new mode from userland with an ioctl.
>:(hint: instead of the index, put a pointer to the struct fd_type into
>:the fd_data structure.)
>:
>:Preferably, send one patch per step rather than one huge patch since that
>:will make reviewing easier.
>:
>:First volounteer to send me email gets the assignment.
>:
>:-- 
>:Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
>:[EMAIL PROTECTED] | TCP/IP since RFC 956
>:FreeBSD committer   | BSD since 4.3-tahoe
>:Never attribute to malice what can adequately be explained by incompetence.
>:
>:To Unsubscribe: send mail to [EMAIL PROTECTED]
>:with "unsubscribe freebsd-hackers" in the body of the message
>:
>
>--
>Andrew R. Reiter
>[EMAIL PROTECTED]
>[EMAIL PROTECTED]
>
>

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: SMP beeping

[Chad David]

On Tue, Dec 11, 2001 at 10:12:35AM -0500, Matthew Emmerton wrote:
> On Mon, 10 Dec 2001, Chad David wrote:
> 
> > I sent a message about this to -stable last week, but didn't get any
> > input that resulted in a solution to this problem so...
> > 
> > -stable for the last week or more (I did a make world last week for
> > the first time in over a month) beeps on and off when SMP is enabled.
> > The beeping appears to be timed with very short stalls of the system;
> > that is, when moving the mouse across the screen it stops at what
> > seems to be that start of each beep.  The beeps are not consistent
> > in length, but the tone does not change.  If I boot a kernel with
> > the exact same config only with SMP disabled it does not beep, and
> > mouse cursor movement is fluid.
> 
> You never mentioned that the beeps were caused by moving your mouse
> before!

I didn't mention it because that is not what is does :).  If you read
the above you will notice that I am still not saying that.  What I was
saying was that there is a noticable pause in the system when ever a
beep begins (every 1/2 sec - 1 sec), and the mouse is an obvious indicator
of that.

My assumption is that either something is beeping on purpose (there is a
hardware/bios/kernel problem that I do not know about), or something in
the kernel is writing to a bad address when SMP is enabled.  I was hoping
that somebody was having the same problem or would at least have a better
idea then I do.

> 
> Are you using a KVM?  If so, does this problem occur when using a mouse
> that is directly connected to you system?

Both with and without the switch it beeps.  This machine has been runing
for months without any problems... the only change was a make world, and
a new kernel.  The kernel I am running is basically GENERIC with SMP
enabled.

Since it appears nobody else is having the same problem, I guess I will
pull the box out of production, and hack on it.  I was hoping not to have
to do that (my fault for putting -stable on it in the first place I guess).

-- 
Chad David[EMAIL PROTECTED]
ACNS Inc. Calgary, Alberta Canada

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Junior Kernel hacker task: Floppy driver mode handling.

[Andrew R. Reiter]

Someone already doing this?  If not, I'm down.

On Tue, 11 Dec 2001, Poul-Henning Kamp wrote:

:
:There exists a patch for adding a mode to our floppy driver to
:add DEC RX50 media handling.
:
:The crucial part of this is the addition of this line:
:{ 10,2,0xFF,0x10,80, 800,1,FDC_300KBPS,1,0x2E,1 }, /*  400K DEC RX50 */
:
:But if one examines the fd.c driver, one cannot help but notice that the
:handling of densities is a bit convoluted, to put it mildly.
:
:I'm looking for a volounteer to do this, it is a quite simple job and
:I am quite sure that practically everybody has the hardware they need to
:do this :-)
:
:Cleaning it up consists of the following steps:
:
:1.  Define a new set of (bitmap) macros to distinguish the drive type:
:   #define FD_3S   0x0001  /* 3.5" single density */
:   #define FD_5S   0x0002  /* 5.25" single density */
:   ...
:And use these instead of the FD_1200 and similar in 
:struct fd_data->type.
:
:2.  Augment the struct fd_type with two new fields:
:   int minor;  /* minor device encoding */
:   int drives; /* bitmap of compatible drives (FD_[35][SD]) */
:And fill these fields out in the fd_types[NUMTYPES] array.
:Add a termination entry at the end of the table so the
:NUMTYPES, NUMDENS, and FD_%d[5_25] #defines can be eliminated.
:
:3.  Change the _clone code to use the new "minor" field instead of
:the private table it uses now.  (Eliminate and avoid any
:use of NUMTYPES, NUMDENS and FD_%d[5_25]).
:
:4.  Change the code in Fdopen to examine the "drives" field in the
:fd_types[] array instead of the hardcoded switch.  (Eliminate
:and avoid any use of NUMTYPES, NUMDENS and and FD_%d[5_25]);
:
:5.  Remove any other use of NUMTYPES, NUMDENS and FD_%d[5_25]
:
:6.  Add the "rx50" entry from above to the table to show how simple
:that is now.
:
:7.  Make it possible to define a new mode from userland with an ioctl.
:(hint: instead of the index, put a pointer to the struct fd_type into
:the fd_data structure.)
:
:Preferably, send one patch per step rather than one huge patch since that
:will make reviewing easier.
:
:First volounteer to send me email gets the assignment.
:
:-- 
:Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
:[EMAIL PROTECTED] | TCP/IP since RFC 956
:FreeBSD committer   | BSD since 4.3-tahoe
:Never attribute to malice what can adequately be explained by incompetence.
:
:To Unsubscribe: send mail to [EMAIL PROTECTED]
:with "unsubscribe freebsd-hackers" in the body of the message
:

--
Andrew R. Reiter
[EMAIL PROTECTED]
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Junior Kernel hacker task: Floppy driver mode handling.

[Poul-Henning Kamp]

There exists a patch for adding a mode to our floppy driver to
add DEC RX50 media handling.

The crucial part of this is the addition of this line:
{ 10,2,0xFF,0x10,80, 800,1,FDC_300KBPS,1,0x2E,1 }, /*  400K DEC RX50 */

But if one examines the fd.c driver, one cannot help but notice that the
handling of densities is a bit convoluted, to put it mildly.

I'm looking for a volounteer to do this, it is a quite simple job and
I am quite sure that practically everybody has the hardware they need to
do this :-)

Cleaning it up consists of the following steps:

1.  Define a new set of (bitmap) macros to distinguish the drive type:
#define FD_3S   0x0001  /* 3.5" single density */
#define FD_5S   0x0002  /* 5.25" single density */
...
And use these instead of the FD_1200 and similar in 
struct fd_data->type.

2.  Augment the struct fd_type with two new fields:
int minor;  /* minor device encoding */
int drives; /* bitmap of compatible drives (FD_[35][SD]) */
And fill these fields out in the fd_types[NUMTYPES] array.
Add a termination entry at the end of the table so the
NUMTYPES, NUMDENS, and FD_%d[5_25] #defines can be eliminated.

3.  Change the _clone code to use the new "minor" field instead of
the private table it uses now.  (Eliminate and avoid any
use of NUMTYPES, NUMDENS and FD_%d[5_25]).

4.  Change the code in Fdopen to examine the "drives" field in the
fd_types[] array instead of the hardcoded switch.  (Eliminate
and avoid any use of NUMTYPES, NUMDENS and and FD_%d[5_25]);

5.  Remove any other use of NUMTYPES, NUMDENS and FD_%d[5_25]

6.  Add the "rx50" entry from above to the table to show how simple
that is now.

7.  Make it possible to define a new mode from userland with an ioctl.
(hint: instead of the index, put a pointer to the struct fd_type into
the fd_data structure.)

Preferably, send one patch per step rather than one huge patch since that
will make reviewing easier.

First volounteer to send me email gets the assignment.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: SMP beeping

[Matthew Emmerton]

On Mon, 10 Dec 2001, Chad David wrote:

> I sent a message about this to -stable last week, but didn't get any
> input that resulted in a solution to this problem so...
> 
> -stable for the last week or more (I did a make world last week for
> the first time in over a month) beeps on and off when SMP is enabled.
> The beeping appears to be timed with very short stalls of the system;
> that is, when moving the mouse across the screen it stops at what
> seems to be that start of each beep.  The beeps are not consistent
> in length, but the tone does not change.  If I boot a kernel with
> the exact same config only with SMP disabled it does not beep, and
> mouse cursor movement is fluid.

You never mentioned that the beeps were caused by moving your mouse
before!

Are you using a KVM?  If so, does this problem occur when using a mouse
that is directly connected to you system?

--
Matt Emmerton



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: sscanf(..., "%lld", ...) broken?

[Bill Fenner]

>Is this PR-worthy?

Not really; the C99 conformance project is already working on this
(in particular, I am working on scanf).

  Bill

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Motion for removal of xargs(1) from base system

[Eugene L. Vorokov]

> My, is it April 1st already?  How quickly time flies!  December feels
> like it was just yesterday!
> 
> - Jordan

Ehe, as far as I can see some people even have taken it seriously :) This
probably shows that when you have to read 300 emails/day, your attention
slowly but constantly leaves you. :)

I think the original author's point was to write some rant about recent
removal of some frequently used (as he thinks) tools from the base system.
At least I had fun reading it :)

Regards,
Eugene


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: irq

[Terry Lambert]

Danny Braniss wrote:
> 
> > It looks like IRQ sharing is the only issue here.
>
> Q: are all interrupt handlers for the shared irq called, or only the
>'correct' one?

All interrupt handlers are polled -- asked if they have work to do,
on the basis of having caused the interrupt.

Some cards do not have a hardware "I caused an interrupt" register,
and use a differential (e.g. ring head vs. tail inequal after
interrupt) to tell if there is work to do.  If these cards were to
share interrupts, then they most likely do work every interrupt,
and less work per interrupt, then would otherwise be the case (i.e.
it would defeat hardware interrupt coelescing thresholds, among
other things).


> [...]
> 
> > But I would still blame software (in particular, the firmware on
> > your Meteor).
> >
> > -- Terry
> 
> isn't firmware another word for hardware :-)?

No, because you can fix firmware in software, but you can't fix
hardware in software, and get anywhere near the performance (e.g.
CMD640B, etc.).  For example, you could use the PCI bus management
code to ensure broken cards got seperate interrupts from all other
cards.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Hiten Pandya]

that would be nice i suppose.. :-)

BTW, where is this non-GPL code.. i wouldn't mind
putting my hands on it and working on it...

=Hiten
=<[EMAIL PROTECTED]>

--- Terry Lambert <[EMAIL PROTECTED]> wrote:
> Maxim Sobolev wrote:
> > > OK, I load the kernel from the JFS.  I mount the
> root FS, which
> > > is a JFS.  I read the module "jfs.ko" from the
> JFS so that I can
> > > mount the root FS, which is a JFS, so I can read
> the module "jfs.ko"
> > > from the JFS so that I can mount the root FS,
> which is a JFS, so I
> > > can read the module "jfs.ko" from the JFS so
> that I can mount the
> > > root FS, which is a JFS, so I can...
> > >
> > > Do you see the problem yet?
> > 
> > Libstand (and hence the loader) could be extended
> to allow reading
> > files from jfs without using any GPL'ed code. For
> example our loader
> > can load modules from the FAT even though we do
> not have any M$ code.
> > :) Alternatively, /boot could be placed on
> separate filesystem, which
> > could be ufs or anything else supported by the
> loader.
> 
> Patches appreciated.
> 
> Note that if you do a read-only JFS, you are more
> than half way there
> to a n0n-GPL'ed implementation, so you might as well
> finish it off,
> instead of porting the IBM code.
> 
> -- Terry


=
-Hiten,

Thank You,
Yours Sincerely,
Hiten Pandya,
<[EMAIL PROTECTED]>


__
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Terry Lambert]

Peter Wemm wrote:
> It is not a problem.  The *kernel* does not load jfs.ko, it is loader
> itself. There is no reason why a trivial non-gpl jfs reader couldn't be
> written for boot2 and loader if the need was great enough.  Or have /boot
> as a seperate file system (eg: UFS or FAT32).  We do this on IA64 where
> /boot is a FAT32 filesystem (not exactly, but close enough.  I usually
> mount it on /efi and make /boot/ a symlink to /efi/boot so that in EFI
> we have a /boot as well).

JFS patches?
Sysinstall patches?
/usr/src/lib/stand patches?
/usr/src/sys/boot/* patches?

8^).

--- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Terry Lambert]

Maxim Sobolev wrote:
> > OK, I load the kernel from the JFS.  I mount the root FS, which
> > is a JFS.  I read the module "jfs.ko" from the JFS so that I can
> > mount the root FS, which is a JFS, so I can read the module "jfs.ko"
> > from the JFS so that I can mount the root FS, which is a JFS, so I
> > can read the module "jfs.ko" from the JFS so that I can mount the
> > root FS, which is a JFS, so I can...
> >
> > Do you see the problem yet?
> 
> Libstand (and hence the loader) could be extended to allow reading
> files from jfs without using any GPL'ed code. For example our loader
> can load modules from the FAT even though we do not have any M$ code.
> :) Alternatively, /boot could be placed on separate filesystem, which
> could be ufs or anything else supported by the loader.

Patches appreciated.

Note that if you do a read-only JFS, you are more than half way there
to a n0n-GPL'ed implementation, so you might as well finish it off,
instead of porting the IBM code.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: cable modem connection problem

[S. Aeschbacher]

Hiten Pandya wrote:
> 
> >what kind of "mucking" could cause such kind of
> >behaviour?.
> 
> this kind of problem did occur to me several times
> with NTL (http://ntl.com/) in UK...
> 
> there were installing a Universal Shared Bandwith
> Router in their CO (Central Office), after they
> installed this piece of sh*t, the bandwith was
> throttled from 5.00pm evening to 5.00am morning,
> which was to slow down users from downloading large
> files i.e. Music Sharing and such
> 
> but after 5.00am, it was all fine and back to 85.0KBps
> when before 5.00am and after 5.00pm was around
> 12.0KBps
> which is sad but was true for a while till users
> complained about it... (like me)...
And the problems went away when they stopped limiting the
bandwidth?

> so that is a possibility, or it could be that the
> signal you are receiving (cable modem signal) is very
> weak thats a possibility too...
If this was the problem, it could not be solved by deleting
the arp entries.

Stefan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: cable modem connection problem

[S. Aeschbacher]

Lars Eggert wrote:
> 
> S. Aeschbacher wrote:
>  > This is possible, but I did not verify it (what kind of "mucking"
>  > could cause such kind of behaviour?). most of them are "better"
>  > residental pipes.
> 
> Having a packet filter drop your traffic after you haven't done ARP/DHCP
> in a while. But I agree that's pretty far-fetched.
As I said, seems to be more of a modem problem, but the people from the
local provider don't really seem to know what they are doing most of the
time (this is only one of several problems they have, e.g. mail and dns
which often do not work), so all is possible.

>  > The problem seems to occur only on Samsung modems.
> 
> Ah! Another data point. Then I'd assume it's the modem. Have you tried
> powercycling it? (That should keep the ARP cache on the client intact).
> Tried to email Samsung? Is there a firmware update?
IIRC powercycling did not help (and for most clients this is no solution
as isn't rebooting the gateway). As soon as I found the arp workaround,
the problem was solved for me and I did not investigate more.

>  > Cannot confirm this as i don't use windows. I heard of a friend of
>  > mine, that he has running a windows ftp-server for days on a pipe
>  > from the same provider with another modem (a Com21) and that he is
>  > not experiencing any of the problems mentioned.
> 
> Can he/she tcpdump for ARP packets? Maybe Windows' ARP cache timeout is
> lower than FreeBSD's.
I see what I can do to find this out (actually this could be measured
with
any windows machine, maybe somone with windows machines in his net could 
make a quick tcpdump session?)

Stefan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: KLDs vs static linking

[Danny Braniss]

I use them - where possible - when i have the same kernel for different boxes
and i can configure the differences via klm's.

danny

> Hi Folks,
> 
> Hopefully a quick question.
> 
> Is there any reason to prefer KLD modules for drivers etc over static
> linking? For example, KLDs are covenient, loading and unloading for
> development but is it a case of using KLD modules for development then
> building drivers statically into the kernel when development is complete.Or
> is it a case of KLDs are now supported and are the preferred method of
> development moving forward. I've read the online KLD docs, developed the
> code and greped through kern_linker.c so I understand how to develop KLDs it
> but would like to supplement my understanding.
> 
> Thanks in advance,
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Tangent for discussion: FreeBSD performs worse that Linux

[Michael Lucas]

On Tue, Dec 11, 2001 at 05:48:19AM -0600, D J Hawkey Jr wrote:
> > J D, you have an idea. 
> 
> "D J", actually. But "Dave" or "Hawk" gets my attention faster.

Mea culpa.  Please blame this on four hours sleep, followed by four
hours blindly running Oracle's "adpatch" before the DBAs arrive...

Personally, I respond to just about anything, including "Hey, Loser!"

> > In fact, if you do it well, you might even find a vaguely well-known
> > BSD columnist picking up your site in a future article.
> 
> Ack. Don't do that. Sooner or later, the economy will pick up again, I'll
> get myself the badly-needed job I lost, and my play-time will once again
> be reduced by a factor of four. The last thing I'll need then is any kind
> of publicity.

Well, hang on here a second.  I'd say you want publicity for exactly
that reason.  Eventually, you'll move on to other things.  We want
someone else to pick up when you depart.  I strongly recommend you
plan for your successor to come along.  Don't worry about who that
person is, just leave them an opening.  Some poor slob who is hooked
on your service will have no choice but to handle it when you're too
busy to, and the whole community will benefit.  :)

For example, I'm working on the FAQ right now.  If you check various
parts of the FAQ, you'll see that they were originally maintained by
jkh, nik, and a long list of other people, all at different times.
They would want someone to pick up where they left off.  At some
point, someone will succeed me as the FAQ "interested party".

==ml

-- 
Michael Lucas
[EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.blackhelicopters.org/~mwlucas/
Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Hiten Pandya]

hi,

BTW, i am a first timer at porting a file system...

if the proffesionals think that it is not wise or
useful to port the FS (especially IBM's), it is OK,

but, just in case, anyone else (more than three
people)
would like to port this FS to FreeBSD, my target would
be to get it done by September 2002, if we work in a
group...

i dont have web-space where i can host this project,
and we would need a mailing list... probably

freebsd-jfs would help..
and http://people.freebsd.org/~bsdjfs

but thats only if three of more people are _really_
interested in porting it... cause as you know...
porting an IBM file system (from looks) is not a 
one man job :-)

=Hiten
=<[EMAIL PROTECTED]>

> What mail client do you use? It seems to be playing
> havoc with your 
> line breaks.

Sorry, as you know, i am only 15 years old, and my
dad has no plans to get me a pop account and let me
have my machine on 24/365 jus' to receive mail.. :-(

but... i use Yahoo! Mail, which if by far the fastest
mail i am using at the moment... i used to have
hotmail
but as you know Microsft-Hotmail.. so i  left it..

You can point me to a better free mail account, which
i can use in conjuction with my FreeBSD system having
to keep it on 24/7

> Yes, but your plans do involve making FreeBSD
> contain potentially 
> more GPL'ed code than it already does. There are
> good reasons to keep 
> GPL code away from the rest of the source (Legal and
> emotive).

well.. yeah

=Hiten
=<[EMAIL PROTECTED]>

=
-Hiten,

Thank You,
Yours Sincerely,
Hiten Pandya,
<[EMAIL PROTECTED]>


__
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Tangent for discussion: FreeBSD performs worse that Linux

[D J Hawkey Jr]

Geez. Don't some of you sleep, either?

On Dec 11, at 06:14 AM, Michael Lucas wrote:
> 
> > My current plans are to have several patchfiles, grouped by subject (bugfix
> > and/or enhancement), and subordinately grouped by FreeBSD release:
> > 
> >   ich_sound-patch-4.2REL.udiff delayed_ack-patch-4.2REL.udiff
> >   ich_sound-patch-4.3REL.udiff delayed_ack-patch-4.3REL.udiff
> >   ich_sound-patch-4.3STA.udiff agp_for_xf86-patch-4.2REL.udiff
> > 
> > You get the idea.
> 
> Excellent

Well, as Mr. Watson pointed out, there are better ways, but for an initial
rollout, I don't think that level of sophistication is required.

> Other people will help with QA, if this takes off.  Believe me, if a
> patch blows up a system you'll hear about it.

:-)

> > Hey, I'm not taking _anything_ away from y'all; I think all the BSDs are
> > outstanding products. I'm just gonna see if I can't fulfill what I percieve
> > as a support deficiency (again, from my own perspective) in my own little
> > way.
> 
> That's the only way anything gets done around here; someone sees a
> need, and fills it.  The only question is, is this a need?  From
> watching the mailing lists, I certainly think it is.
> 
> The point is this:
> 
> J D, you have an idea. 

"D J", actually. But "Dave" or "Hawk" gets my attention faster.

> Your messages have been read by most of the
> readers of this mailing list.  You have gotten a "do it!" from a few
> people, including a -core member.  You have gotten a few side comments
> from other developers, such as Matt Dillon's comment on your future in
> the flame wars.  So, people have actually read this thread.  I might
> be wrong, but I don't believe that you have received a message saying
> "Your idea sucks!"  You have also received a few comments on other
> ways this can be handled; this should be taken in the spirit in which
> it is meant, which is "It's a good idea, here's how you could improve
> it."
> 
> In FreeBSD, this is what passes for "management buy-in."
> 
> So, I officially challenge you: are you going to do it, or is this
> going to wither on the vine like every other time it's been suggested?
> Consider the gauntlet thrown (in the kindest possible manner, mind
> you).  Put up an initial patchset, announce it here and on, say,
> daily.daemonnews.org, list an email address for patches on the web
> page, and see what happens.

No challenge necessary. I, too, believe the general attitude is "Go for it.".
So I'm going to. It won't be much to look at initially - maybe ever - but
I'll bring it up and see what happens. It'll take a few days, but I'll post
an "It's here." when it's here. BTW, am I allowed to use the daemon mascot?

I spent some time yesterday browsing cvs-all@, and got another little patch
that backported easily and fixed a nagging problem I've had since day two
(that AGP patch in the above example).

> In fact, if you do it well, you might even find a vaguely well-known
> BSD columnist picking up your site in a future article.

Ack. Don't do that. Sooner or later, the economy will pick up again, I'll
get myself the badly-needed job I lost, and my play-time will once again
be reduced by a factor of four. The last thing I'll need then is any kind
of publicity.

> ==ml

Thanks for all the encouragement and feedback,
Dave

-- 
  __ __
  \__   \D. J. HAWKEY JR.   /   __/
 \/\ [EMAIL PROTECTED]/\/
  http://www.visi.com/~hawkeyd/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

KLDs vs static linking

[Dragon Fire]

Hi Folks,

Hopefully a quick question.

Is there any reason to prefer KLD modules for drivers etc over static
linking? For example, KLDs are covenient, loading and unloading for
development but is it a case of using KLD modules for development then
building drivers statically into the kernel when development is complete.Or
is it a case of KLDs are now supported and are the preferred method of
development moving forward. I've read the online KLD docs, developed the
code and greped through kern_linker.c so I understand how to develop KLDs it
but would like to supplement my understanding.

Thanks in advance,


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Dominic Marks]

On Tuesday 11 December 2001 10:26 am, Hiten Pandya wrote:
> > [... Hiten want's to GPL'ify FreeBSD ...]
>
> hi,
> first of all, i would like to clear of some point
> which
> have been taken wrongly.
>

What mail client do you use? It seems to be playing havoc with your 
line breaks.

> o  My Intentions were never to GPL'ify FreeBSD :-)

Yes, but your plans do involve making FreeBSD contain potentially 
more GPL'ed code than it already does. There are good reasons to keep 
GPL code away from the rest of the source (Legal and emotive).

> o  The reason i started this discussion was because
>i think JFS/JFS2 would be a nice addition to
>FreeBSD like the rest of the other filesystems.

While I have nothing against JFS support in any way and I suppose it 
would be a nice addition for some users, what does it really offer 
that is going to be of use to most FreeBSD users? Commercial ones or 
otherwise. From the people I've discussed JFS with they seem to agree 
that its best features are in volume administration (In their 
opinion) - are the management tools part of the GPL'ed code base at 
all? If not I think it would be more useful improving what we already 
have, UFS.

> o  The JFS does _not_ have to be root, and even if
>people were to download it because it is GPL'ed,
>the size of the filesystem is only around 1.0MB

Okay, but if people do use it and do want it for their system, 
including as the root filesystem then it is a problem to be resolved. 
Since quite a few of the pre-existing filesystems (UFS, NFS, ISO9660) 
do have ability to work in this manner.

> o  Statistically, not everyone is going to run after
>IBM's JFS, when there are other similar File
> Systems

Yes, but I hope your not planning to port them all :)

> o  If people did want JFS, they can download it of
>our website, say http://www.FreeBSD.org/~jfs
>
> o  It can also be a child project, like the JAVA
>Project.

This is okay but adds complexity from your point of view as well as 
the end user. One of the best things about the BSDs as opposed to 
Linux for example is that in general I do not have to apply any (or 
many) patches to the kernel. 

> o  I think, (personally), that we migh be able to get
>more Corporates attracted, if we take the step of
>porting quality (not exactly) GPL'ed technologies
>for FreeBSD (my personal thoughts)

Corporate investment is like dynamite. It can be a very useful tool 
for getting things done, and it can also blow up in your face.

> o  It is hard to Port AIX or OS/2 based code, but we
>have to agree that, BSD Users were meant to take
>that kind of challenges, have taken before
>
> o  The JFS, can just be a bonus addition for FreeBSD,
>and does not have to be part of the base addition,
>example: CD-ROMS /DVD or any other releases which
>prohibit GNU Code.
>
> =
> -Hiten,
>

Thanks
-- 
Dominic

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Tangent for discussion: FreeBSD performs worse that Linux

[Michael Lucas]

On Mon, Dec 10, 2001 at 05:32:06PM -0600, D J Hawkey Jr wrote:
> Don't get me wrong - I don't expect the same level of support from the
> FreeBSD Project than I would from, say, Sybase or Sun. Having said that,
> I think FreeBSD's is outstanding, even compared to some other commercial
> *cough*Microsquish(tm)*cough* entities.

Yep, that's why we're here.  Glad you think so, mind you!

> My current plans are to have several patchfiles, grouped by subject (bugfix
> and/or enhancement), and subordinately grouped by FreeBSD release:
> 
>   ich_sound-patch-4.2REL.udiff delayed_ack-patch-4.2REL.udiff
>   ich_sound-patch-4.3REL.udiff delayed_ack-patch-4.3REL.udiff
>   ich_sound-patch-4.3STA.udiff agp_for_xf86-patch-4.2REL.udiff
> 
> You get the idea.

Excellent

Other people will help with QA, if this takes off.  Believe me, if a
patch blows up a system you'll hear about it.

> Hey, I'm not taking _anything_ away from y'all; I think all the BSDs are
> outstanding products. I'm just gonna see if I can't fulfill what I percieve
> as a support deficiency (again, from my own perspective) in my own little
> way.

That's the only way anything gets done around here; someone sees a
need, and fills it.  The only question is, is this a need?  From
watching the mailing lists, I certainly think it is.

> PS, I'm rather honored that such an illustrious group has shown
> interest enough to even discuss all this with me.

You know, I think I'm going to write an article on this, I say it
often enough.

#include 

The FreeBSD group is really not that illustrious.  Some of us are --
if Bruce Evans speaks, we all shut up and listen.  We are simply the
people who do the work.  Everything that is done, is done because
someone thought there was a need.  I got my start in the FreeBSD
community back in 1999 by writing articles.  This isn't something that
*directly* benefits the Project; it adds nothing to the CVS repo, and
doesn't get me the coveted @freebsd.org email address.  It's
important, however, and something that I am very well-qualified to do.
So I shut up, and did it.  It got me a certain amount of recognition
and respect in the community, it was fun, and it satisfied my itch to
solve a problem.

There is a huge amount of basic grunt work that can be done.  Nobody
bothers to do it, so it doesn't happen.  People such as you and I can
ease a vital gap by simply picking some little hole, and doing the
work to fill it.  It's not glamorous.  It's not exciting.  But it lets
people like $YOURFAVORITECODECOMMITTER get on with stuff that only
they can do.

Lots of people say that they want to help.  Lots of people make
suggestions.

Some make suggestions that are well beyond their ability to perform.
In this case, those suggestions are usually either obvious ("Hey,
wouldn't it be cool if FreeBSD supported FireWire?") or clueless ("Why
don't we have a kernel option READMYMINDANDDOWHATIWANT?").  These
suggestions are generally ignored; both would be good ideas, but one
requires convincing a developer to pick it up and the other is
brain-dead.

Some suggestions are within the ability of the people making the
suggestion.  Posting on a mailing list and saying "Hey, would this be
a good idea?" is a great way to tell if you have a boneheaded idea, or
if you have a serious need.  Your case is a great example of this.

You can't expect a thousand people to write back and say "Oh, it's a
good idea."  This is a public discussion board, and everyone on it
gets far too much email as-is.  If we read something we agree with, we
aren't going to all post "me too!"  But if you get a few people
publically agreeing with you, and nobody says "Your idea sucks!", you
can generally assume that it's a decent idea.

Once you have buy-in, go *DO IT*.  I've seen a lot of decent ideas
come across the FreeBSD mailing lists since 1996.  Most of them die on
the vine.

The point is this:

J D, you have an idea.  Your messages have been read by most of the
readers of this mailing list.  You have gotten a "do it!" from a few
people, including a -core member.  You have gotten a few side comments
from other developers, such as Matt Dillon's comment on your future in
the flame wars.  So, people have actually read this thread.  I might
be wrong, but I don't believe that you have received a message saying
"Your idea sucks!"  You have also received a few comments on other
ways this can be handled; this should be taken in the spirit in which
it is meant, which is "It's a good idea, here's how you could improve
it."

In FreeBSD, this is what passes for "management buy-in."

This is not the first time I've seen this idea on this mailing list.
I sincerely, devoutly hope that it is the last.

So, I officially challenge you: are you going to do it, or is this
going to wither on the vine like every other time it's been suggested?
Consider the gauntlet thrown (in the kindest possible manner, mind
you).  Put up an initial patchset, announce it here and on, say

Re: [SUGGESTION] - JFS for FreeBSD

[Hiten Pandya]

> [... Hiten want's to GPL'ify FreeBSD ...]

hi,
first of all, i would like to clear of some point
which
have been taken wrongly.

o  My Intentions were never to GPL'ify FreeBSD :-)

o  The reason i started this discussion was because
   i think JFS/JFS2 would be a nice addition to
   FreeBSD like the rest of the other filesystems.

o  The JFS does _not_ have to be root, and even if
   people were to download it because it is GPL'ed,
   the size of the filesystem is only around 1.0MB

o  Statistically, not everyone is going to run after
   IBM's JFS, when there are other similar File
Systems

o  If people did want JFS, they can download it of
   our website, say http://www.FreeBSD.org/~jfs

o  It can also be a child project, like the JAVA
   Project.

o  I think, (personally), that we migh be able to get
   more Corporates attracted, if we take the step of
   porting quality (not exactly) GPL'ed technologies
   for FreeBSD (my personal thoughts)

o  It is hard to Port AIX or OS/2 based code, but we
   have to agree that, BSD Users were meant to take
   that kind of challenges, have taken before

o  The JFS, can just be a bonus addition for FreeBSD,
   and does not have to be part of the base addition,
   example: CD-ROMS /DVD or any other releases which
   prohibit GNU Code.






=
-Hiten,

Thank You,
Yours Sincerely,
Hiten Pandya,
<[EMAIL PROTECTED]>


__
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: irq

[Danny Braniss]

> It looks like IRQ sharing is the only issue here.
> 
Q: are all interrupt handlers for the shared irq called, or only the
   'correct' one?
[...]

> But I would still blame software (in particular, the firmware on
> your Meteor).
> 
> -- Terry

isn't firmware another word for hardware :-)?

danny



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Peter Wemm]

Terry Lambert wrote:
> Greg Lehey wrote:
> > Since then, it has become possible for the loader to load modules
> > before booting the kernel.  This means that, theoretically, it would
> > be possible to have a JFS root file system.  Given the strong
> > opposition to the GPL in some factions of the FreeBSD project, I don't
> > see this happening any time soon, especially since we still don't know
> > if it will buy us anything.
> 
> ?
> 
> OK, I load the kernel from the JFS.  I mount the root FS, which
> is a JFS.  I read the module "jfs.ko" from the JFS so that I can
> mount the root FS, which is a JFS, so I can read the module "jfs.ko"
> from the JFS so that I can mount the root FS, which is a JFS, so I
> can read the module "jfs.ko" from the JFS so that I can mount the
> root FS, which is a JFS, so I can...
> 
> Do you see the problem yet?

It is not a problem.  The *kernel* does not load jfs.ko, it is loader
itself. There is no reason why a trivial non-gpl jfs reader couldn't be
written for boot2 and loader if the need was great enough.  Or have /boot
as a seperate file system (eg: UFS or FAT32).  We do this on IA64 where
/boot is a FAT32 filesystem (not exactly, but close enough.  I usually
mount it on /efi and make /boot/ a symlink to /efi/boot so that in EFI
we have a /boot as well).

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Maxim Sobolev]

Terry Lambert wrote:
> 
> Greg Lehey wrote:
> > Since then, it has become possible for the loader to load modules
> > before booting the kernel.  This means that, theoretically, it would
> > be possible to have a JFS root file system.  Given the strong
> > opposition to the GPL in some factions of the FreeBSD project, I don't
> > see this happening any time soon, especially since we still don't know
> > if it will buy us anything.
> 
> ?
> 
> OK, I load the kernel from the JFS.  I mount the root FS, which
> is a JFS.  I read the module "jfs.ko" from the JFS so that I can
> mount the root FS, which is a JFS, so I can read the module "jfs.ko"
> from the JFS so that I can mount the root FS, which is a JFS, so I
> can read the module "jfs.ko" from the JFS so that I can mount the
> root FS, which is a JFS, so I can...
> 
> Do you see the problem yet?

Libstand (and hence the loader) could be extended to allow reading
files from jfs without using any GPL'ed code. For example our loader
can load modules from the FAT even though we do not have any M$ code.
:) Alternatively, /boot could be placed on separate filesystem, which
could be ufs or anything else supported by the loader.

-Maxim

> > >> It is used on IBM MainFrames and Enterprise servers
> > >> for high performance and maximum throughput...
> > >
> > > No, it's not.  The Linux JFS is derived from the OS/2 JFS code, not
> > > the good AIX JFS code.
> >
> > That's correct, but note that AIX is moving to this code base too, so
> > it's not as if it's second-rate.  From what I've seen of the
> > structures, JFS2 is *much* better than JFS1.  I haven't compared
> > performance.
> 
> None of the Web Connections RS/6000 machines ran this OS/2 derived
> code.  I was under the impression that it was there for Linux
> compatability.  My impression is, layout or not, the original JFS
> is much better code, overall.
> 
> -- Terry
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: irq

[Terry Lambert]

Danny Braniss wrote:
> well, if it's not software it must be hardware problem (true or false ?)
> the test:
> video capture (using a modified meteor driver)
> doing full size 24bit colour, the meteor would complain about FIFO errors
> (which probably mean that the dma did not finish in time - correct?)
> and sometimes, the adaptec would also complain.
> 
> so i moved cards around.
> 
> 1st try: disaster, the adaptec realy complained, had to reboot.
> 2nd try: Success, fifo errors are down to less than .1% (before it
> used to be 90%).

It looks like IRQ sharing is the only issue here.

I don't see this as a hardware problem, unless tou are complaining
about the Meteor design (which I'd probably agree with).  Sharing
of IRQs is supposed to be possible, but if you have incredible bus
on times and incredible "I caused this interrupt" register access
latency, and are stacking captures into writes ont disk serviced at
the same interrupt, well, then, you should expect problems.

But I would still blame software (in particular, the firmware on
your Meteor).

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Terry Lambert]

Greg Lehey wrote:
> > FS porting to FreeBSD is actually pretty trivial(*), though some
> > transactioning changes to the FreeBSD VFS layer consumers (the
> > system calls and NFS server code) would be necessary to make
> > the journal roll-back function correctly, following a failure.
> >
> > (*) Trivial: meaning grunt work is required; not necessarily an
> > indicator of the amount of work, only the intellectual effort
> > required for the job
> 
> Considering that the current UFS implementation didn't need to be
> ported, and people are still working on the details, I think that this
> is a highly misleading statement.

The current UFS has a number of issues which make it non-trivial;
it was, in effect, a port; here is the short list:

o   Soft updates
o   Unified VM and buffer cache
o   Interface is still not entirely reflexive
o   VOP_READDIR restart via cookies, rather than seperate
read/externalize VOPS, which would have avoided cookies
o   Gratuitous difference in cookie parameter order between
FreeBSD and OpenBSD/NetBSD
o   "Default" VOPS considreably complicate stacking, which
appears to be a goal nowm when it wasn't a goal before
o   New block size defaults (what happens to directories,
which require atomicity and therefore use 512b blocks,
is not explained in the 8K/1K case)
o   New directory acceleration code (dirhash; probably
belongs in the directory name cache, not the FS)
o   NFS server code and system call code not treated as
equal consumers of the VFS interface


Live code always has issues, particularly if you are trying to
pound a round peg into a square hole (hence Kirk taking up the
task of a redesign).


FWIW: I was a member of a very small team which ported the entire
Heidemann framework, the UFS and FFS code of the time, and also
implemented Soft Updates and Soft Read Only in 1996 or so.  We
had to port to the Windows 95 IFSMgr framework, add a second
namespace, add Unicode support, deal with the 512b directory
blocks growing to 1024b, while maintaining idempotence in the
face of the loss of atomicity, etc..  Three people did almost
all the work in about 5 months.

The code is _not_ hard to get your head around.

I think that everyone saying "Ut oh!  SCARY!" gives people the
wrong idea, and scares off potential contributors in these areas.

Unlike most of the rest of the system, there are at least white
papers available.  I'd have to say the FS design was one of the
better documented parts of FreeBSD, if you take the many McKusick,
Heidemann, Ganager/Patt papers and articles into account.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: irq

[Danny Braniss]

well, if it's not software it must be hardware problem (true or false ?)
the test:
video capture (using a modified meteor driver)
doing full size 24bit colour, the meteor would complain about FIFO errors
(which probably mean that the dma did not finish in time - correct?)
and sometimes, the adaptec would also complain.

so i moved cards around.

1st try: disaster, the adaptec realy complained, had to reboot.
2nd try: Success, fifo errors are down to less than .1% (before it
used to be 90%).
danny






To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Terry Lambert]

Greg Lehey wrote:
> Since then, it has become possible for the loader to load modules
> before booting the kernel.  This means that, theoretically, it would
> be possible to have a JFS root file system.  Given the strong
> opposition to the GPL in some factions of the FreeBSD project, I don't
> see this happening any time soon, especially since we still don't know
> if it will buy us anything.

?

OK, I load the kernel from the JFS.  I mount the root FS, which
is a JFS.  I read the module "jfs.ko" from the JFS so that I can
mount the root FS, which is a JFS, so I can read the module "jfs.ko"
from the JFS so that I can mount the root FS, which is a JFS, so I
can read the module "jfs.ko" from the JFS so that I can mount the
root FS, which is a JFS, so I can...

Do you see the problem yet?


> >> It is used on IBM MainFrames and Enterprise servers
> >> for high performance and maximum throughput...
> >
> > No, it's not.  The Linux JFS is derived from the OS/2 JFS code, not
> > the good AIX JFS code.
> 
> That's correct, but note that AIX is moving to this code base too, so
> it's not as if it's second-rate.  From what I've seen of the
> structures, JFS2 is *much* better than JFS1.  I haven't compared
> performance.

None of the Web Connections RS/6000 machines ran this OS/2 derived
code.  I was under the impression that it was there for Linux
compatability.  My impression is, layout or not, the original JFS
is much better code, overall.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message