-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 03, 2011, at 19:29 PM, Michael Büsch wrote:
On Fri, 2011-02-04 at 00:47 +0100, Peter Stuge wrote:
You're simply unaware of the basic Unix tools that help you find
what you are searching for.
Not at all. If I was the one looking for the code that talks to
hardware I'd not only know where to find it, but I'd also know every
other component of hardware and software that the data passes through
on the way.
A basic thing about software abstraction is that you do _not_ need
to know what a subsystem does internally. To understand the ssb_sprom
file, you do _not_ have to read one single line of sysfs code.
To understand the whole SSB SPROM writing, you have to read about 200
lines of code.
I see so if I can compile the ssb-sprom program I am able to perform
"flashing" of SPROM's on various Broadcom based wireless cards
without doing anything else, not likely since the kernel may not have
the required support or functionality.
A kernel compiled without the included dependancies and features
doesn't support it and the linux based OS I am familiar with doesn't
require rebuilding the kernel to add support or functionality to do
anything but is not compatible with the the general linux
distributions drivers.
My opinion is that there shouldn't be any dependent code in the
kernel to perform these flashing tasks.
Finding all the code that relates to the Broadcom wireless device and
it's functionality should be inclusive in the b43 code, having to
look outside this code to find code that performs the flashing makes
no sense and the use of nested abstraction layers and code buried in
structs for functionality only makes it difficult for a person not
familiar with the code base to locate anything and my opinion is
there should be no need to look outside the b43 code.
You say you don't have to recompile the kernel to add support for
things, I remember initially working with ubuntu 8.01 and having to
recompile the kernel to add support for the Broadcom wireless cards
because downloading and installing a wireless kernel package someone
else made that only allowed flashing of some cards was useless.
Rewriting the nVidia drivers was something else I did since 8.0.1
didn't seem to support multiple cards and having to install a blob
provided by nvidia to make the card work and seeing this popup
explaining the license of the third-party (nVidia) software was a
waste of time so this was dumped in favor of my own code which
included a HAL source file for the 6k and 7k series cards, not
exactly legally obtained.
After my 8.01 experience I decided that if the OS doesn't come with
the required support it's of no value to me, when the working 10 was
provided on disk I didn't have to do anything or at the very least
only minimal before flashing and since no instructions were provided
telling me that I had to do anything other but reinstall the software
I expected it to work as intended.
Since it seems that wireless support is now pretty much included it's
improving but when stuff doesn't work, someone involved should be
knowledgeable enough to know why and or to suggest commands that
might help isolate the cause of the failure, it might have been user
induced but it appears that after the installation of 10.10 we can
conclude it's not a user related error since it works properly.
Luckily the tool to find something is called "find".
You can tell "find" to find only the code specifically related to
flashing SPROM's???
I think you may have missed my point. One part is certainly to know
how to find a file in a Linux system, but more important is the
question of what to search for (a file) and where to search (in the
kernel codebase). It's not at all obvious to a newcomer where the
kernel edge is, or even that the kernel is so distinct.
I think we're probably drifting offtopic. Why would a newcomer who
doesn't even know what an operating system kernel is want to
write an SSB SPROM? That guy will brick his device anyway, as
he _will_ write incorrect data to the SPROM.
Making assumptions about some ones knowledge or experience is not a
good thing and I have revealed nothing that would make any
intelligent person conclude this with them first asking pertinent
questions.
Stating I will brick cards because you lack the capacity to
distinguish intelligence from frustration doesn't look good on you
and you should have asked questions before making such a grand
assumption, I have flashed more than 10,000 cards and have not
bricked one, I have had cards that I have tried to alter LED behavior
stop functioning because they have unsupported firmware versions that
the application doesn't properly support but I understand that there
is a risk involved in making changes so I limit my changes to avoid
that conundrum.
When you can decode a DXE from an intel motherboard BIOS, contact me,
we might have something we can discuss.
The next thing you'll probably blame on me is that I did not
document in
the b43 documentation how to use a qwerty keyboard.
--
Greetings Michael.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
iD8DBQFNS28siD9DTPch4RQRArguAJwKOPyljoMsinW0P2SXR0X1UzN3VACfS75E
fPwdXvX5/8BCM6IYyoIl/UI=
=T6qS
-----END PGP SIGNATURE-----
_______________________________________________
b43-dev mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/b43-dev
