Re: 2.0.33 is no good for lic6-dev ?
On Fri, May 15, 1998 at 04:11:46PM -0500, Manoj Srivastava wrote: Hmm. if you use -I/usr/src/linux/include, then as far as I can see; it should link with those files (as you state further, it is linked to kernel-source-2.0.33). What toerh files you happen to have elsewhere should not make a difference. How is sndshield getting to know about 2.0.32? Well, try putting in -I/usr/src/linux/include for every file compiled in the tree; and see if that improves things. At the last resort, you can try mkdir /usr/src/tmp; mv the 2.0.32 headers there, and create a symlink from kernel-source-2.0.33 to kernel-headers-2.0.32; compile the module, and restore things to the way they were for the other 99.99% of the code that is well behaved (or less dependent on kernel versions). Thr problem with OSS/Linux is that it grep's autoconf.h to see if you have the right configuration for module support and versioning. This is STUPID and WRONG, but then it's just one more example of what a shoddy piece of crap OSS truly is. (Get the idea this and other features of OSS/Linux have torked me off a bit?) pgpwhLRnS7aVV.pgp Description: PGP signature
Re: 2.0.33 is no good for lic6-dev
On statistical anomalies. Add to that the fact that few programs really need the more volatile elements of the header files (that is, things that really change from kernel version to kernel version), [before you reject this, consider: programs compiled on one kernel version usually work on other kernels]. For the few that do need specific kernel headers, ^ !!! use -I/usr/src/kernel-headers-version or some thing for a specific kernel version, or -I/usr/src/linux/include for the latest set of ^ headers installed.. ^^^ No thank you. Most programs, even if they include linux/something.h, do ^ not really depend on the version of the kernel, as long as the kernel versions are not too far off, they will work. And the headers provided in libc5-dev (and libc6-dev) are just that. The solution is to separate out the two sets of header files: I, for one, applaud Bruce Perens's efforts to standardize various issues. This is one that has continually been a sore point for me, standing in the way, between me and peaceful computing. You are making some assumptions here. You are telling me that this is, after all, not really a standardizable solution, but that Debian will work most of the time, but not all the time, except for hackers who are alert enough to catch this and remember the required kludges. Congratulations on an ingeniously intricate, illusory and superfluous solution to what appears (at least to others who must compile the kernels)to be a trivial problem, or not a problem. In held and in trepidation, for over a year. Save this kludge, the nightmarish dselect, now the fact that apt WON'T EVEN RUN if any of the required packages are self-installed (except for a proxy package setup that won't work), Debian GNU/Linux has been a most pleasing system to use for the past 2-3 years. Say what you will. GNU packages, even emacs20, compile out of the box, and self install. If there were a way (without debianizing or other patch-ification) to have these packages, installed by make, register themselves and completely uninstall themselves, a significant part of the need for self-logging installations (and note the extensive checking done in the ./configure step!) would be met. Imagine a dpkg that would check if a compatible library actually existed on the system! That having been said, it sure is nice to install smail, and have a working mail system. And many programs I couldn't compile myself have been compiled by others and made available. I thank the developers. Alan -- Alan E. Davis Marianas High School (Science Department) AAA196, Box 10001[EMAIL PROTECTED] http://www.saipan.netpci.com/~adavis Saipan, MP 9695015.16oN 145.7oEGMT+10 Northern Mariana Islands -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.0.33 is no good for lic6-dev ?
Rev. Joseph Carter writes: On Fri, May 15, 1998 at 04:11:46PM -0500, Manoj Srivastava wrote: Thr problem with OSS/Linux is that it grep's autoconf.h to see if you have the right configuration for module support and versioning. Sorry I could not quite follow you all the way. Let's see if I got it: since, in a Debian machine, autoconf.h is not at /usr/src/linux/include, because it is at the kernel-headers (and not kernel-source), then what happens? How did it get to think that sndshield was compiled against 2.0.32? Or: was it compiled against 2.0.32? How can I workaround this? This is STUPID and WRONG, What is the right was, then? Maybe OSS people should be suggested a better way, if one exists. I found them to be always very prompt to help me. but then it's just one more example of what a shoddy piece of crap OSS truly is. No offence intended here, but by your reference, then, the kernel sound card support is a shoddy piece of sh*t :^ ... Let's make things better... Thanks a lot! -- Luiz Otavio L. Zorzella Product Engineer [EMAIL PROTECTED] http://www.conexware.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.0.33 is no good for lic6-dev ?
On Fri, May 15, 1998 at 04:11:46PM -0500, Manoj Srivastava wrote: Hi, Well, try putting in -I/usr/src/linux/include for every file compiled in the tree; and see if that improves things. At the last resort, you can try mkdir /usr/src/tmp; mv the 2.0.32 headers there, and create a symlink from kernel-source-2.0.33 to kernel-headers-2.0.32; compile the module, and restore things to the way they were for the other 99.99% of the code that is well behaved (or less dependent on kernel versions). manoj Well...you could do that...but it is MUCH simpler than that first go into /usr/include mv linux linux-deb mv asm asm-deb ln -s /usr/src/linux/include/linux linux ln -s /usr/src/linux/include/asm asm then go into the oss directory and make clean make sndshield once it is finished make sure it works (soundon) then just go back to /usr/include and switch the links back remember...it doesn't even matter whether /usr.include or anything in it exists unless you plan on compiling somethin...so changing it for a short time wont hurt anything (also.. make sure you compile the kernel with th eoption sfor modual version ON..) it has been my experiance that OSS doesn't like the debian stock binary kernel image (from the install) for 2.0.29 ...maybe differnt for 2.0.33 but I had to change some options (I think it was the one I mentioned above...I might be wrong tho) -Steve ** Stephen Carpenter ** ** ** ** ** ** ** ** ** ** ** ** [EMAIL PROTECTED] ** We must respect the other fellow's religion, but only in the sense and to the extent that we respect his theory that his wife is beautiful and his children smart. -- H. L. Mencken (1880-1956) pgplxlOYR3dM5.pgp Description: PGP signature
Re: 2.0.33 is no good for lic6-dev ?
[EMAIL PROTECTED] writes: Well...you could do that...but it is MUCH simpler than that first go into /usr/include mv linux linux-deb mv asm asm-deb ln -s /usr/src/linux/include/linux linux ln -s /usr/src/linux/include/asm asm Change that for: ln -s /usr/src/kernel-headers-2.0.33/include/ and BINGO! It works! Thanks guys. You're always right. I wish to send a mail to the OSS tech support about this situation with debian. Is there anything you think I should suggest to fix the problem in a clean way (all the dists, including Debian)? -- Luiz Otavio L. Zorzella Product Engineer [EMAIL PROTECTED] http://www.conexware.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.0.33 is no good for lic6-dev ?
Hi, Luiz == Luiz Otavio L Zorzella [EMAIL PROTECTED] writes: Luiz I wish to send a mail to the OSS tech support about this Luiz situation with debian. Is there anything you think I should Luiz suggest to fix the problem in a clean way (all the dists, Luiz including Debian)? Yes. Tell them not to use grep. There are ways to include a linux header to tell what kernel version is being used (if they do not know what I mean, tell them to look at the sources of modules in the kernel to determine how to do that). At run time, they can call uname. Using grep and trying to second guess the installation about whivh headers were used is evil, and shoddy software practice. manoj -- May the forces of evil become confused on the way to your house. George Carlin Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.0.33 is no good for lic6-dev
Hi, Alan == Alan Eugene Davis [EMAIL PROTECTED] writes: Alan No thank you. Well, there are other distributions -- red hat makes a fine OS, you know. I just sent you Debian policy. Most programs, even if they include linux/something.h, do Alan ^ not really depend on the version of the kernel, as long as the kernel versions are not too far off, they will work. And the headers provided in libc5-dev (and libc6-dev) are just that. How many programs you know depend on intimate knowledge of kernel headers? pcmcia, and oss are the only ones I know about. The solution is to separate out the two sets of header files: Alan You really seem to have little knowledge of this subject, and do not seem to be able to follow the technica discussion (which, BTW, was endorsed by Linus, had you cared to read to the end) Alan I, for one, applaud Bruce Perens's efforts to standardize Alan various issues. libc6-dev is not part of the base system, and is not likely to be. So, Debian is going to be following a variation of the policy I mailed here. (The real policy for slink is slightly different, but only in implementation details). Alan This is one that has continually been a sore point for me, Alan standing in the way, between me and peaceful computing. Sorry. Alan You are making some assumptions here. You are Alan telling me that this is, after all, not really a standardizable Alan solution, but that Debian will work most of the time, but not Alan all the time, except for hackers who are alert enough to catch Alan this and remember the required kludges. You evidently fail to grasp the subject at hand. I said no such thing. Alan Congratulations on an ingeniously intricate, illusory and Alan superfluous solution to what appears (at least to others who Alan must compile the kernels)to be a trivial problem, or not a Alan problem. What the hell does that have to do with compiling kernels (apart from pieces of crap like OSS)? The kernel is independent of the headers installed on the machine, and delibrately so. Since you do not understand what you are talking about, I think I have nothing further to say on this matter. Technical objects to Debian policy are always welcome, unreasoning rants shall be ignored. Good day. manoj -- ...Another writer again agreed with all my generalities, but said that as an inveterate skeptic I have closed my mind to the truth. Most notably I have ignored the evidence for an Earth that is six thousand years old. Well, I haven't ignored it; I considered the purported evidence and *then* rejected it. There is a difference, and this is a difference, we might say, between prejudice and postjudice. Prejudice is making a judgment before you have looked at the facts. Postjudice is making a judgment afterwards. Prejudice is terrible, in the sense that you commit injustices and you make serious mistakes. Postjudice is not terrible. You can't be perfect of course; you may make mistakes also. But it is permissible to make a judgment after you have examined the evidence. In some circles it is even encouraged. Carl Sagan, The Burden of Skepticism, Skeptical Enquirer, Vol. 12, pg. 46 Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.0.33 is no good for lic6-dev ?
Manoj Srivastava writes: Hi, Luiz == Luiz Otavio L Zorzella [EMAIL PROTECTED] writes: Luiz I wish to send a mail to the OSS tech support about this Luiz situation with debian. Is there anything you think I should Luiz suggest to fix the problem in a clean way (all the dists, Luiz including Debian)? Yes. Tell them not to use grep. There are ways to include a linux header to tell what kernel version is being used (if they do not know what I mean, tell them to look at the sources of modules in the kernel to determine how to do that). At run time, they can call uname. Using grep and trying to second guess the installation about whivh headers were used is evil, and shoddy software practice. Forgive my dumbness... I've been thinking exactly what are the implications of what your're saying. Please correct me if I'm wrong: 1) sndshield, at *compilation time*, greps autoconf.h to guess which kernel version is being used. In my case, since it did not find any at /usr/src/linux/include, it found one at /usr/include, which was a symlink to 2.0.32 headers. This way it thought it was being compiled in a 2.0.32 system. 2) sndshield, at *run time*, does a uname -a (or something) to find which kernel version is being run. In my case it found 2.0.33, and threw a mismatch. 3) Most important: are you saying that even compiled against 2.0.32 headers, since it was compiled under 2.0.33 it was supposed to run without any problem? Question 3 is crutial for what I'm gonna suggest to OSS people. Before you wrote me, I was thinking of suggesting them to -I /usr/src/kernel-headers-`uname -r` in a debian system... Thanks a lot for the support. -- Luiz Otavio L. Zorzella Product Engineer [EMAIL PROTECTED] http://www.conexware.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.0.33 is no good for lic6-dev ?
Hi, Luiz == Luiz Otavio L Zorzella [EMAIL PROTECTED] writes: Luiz Forgive my dumbness... I've been thinking exactly what are the Luiz implications of what your're saying. Please correct me if I'm Luiz wrong: Luiz 1) sndshield, at *compilation time*, greps autoconf.h to guess Luiz which kernel version is being used. In my case, since it did not Luiz find any at /usr/src/linux/include, it found one at Luiz /usr/include, which was a symlink to 2.0.32 headers. This way it Luiz thought it was being compiled in a 2.0.32 system. It depends on whatever is in the directory /usr/src/linux to have any connection whatsover with the kernel one is compiling for. The kernel itself make no such assumptions. I compile kernel in /usr/local/src/kernel. No problems whatsover. Luiz 2) sndshield, at *run time*, does a uname -a (or something) to Luiz find which kernel version is being run. In my case it found Luiz 2.0.33, and threw a mismatch. Probably (I have not looked at the source to see if this is what they are doing) Luiz 3) Most important: are you saying that even compiled against Luiz 2.0.32 headers, since it was compiled under 2.0.33 it was Luiz supposed to run without any problem? Who says it was compiled with 2.0.32 headers? From what I remember, you compiled with cc -I/usr/src/kernel-source-2.0.33/include, which means it was compiled with 2.0.33. The stupidityis that it knew better than you. It knew that the kernel sources are always always in /usr/src/linux. The correct way to do this is to include linux/version.h and compare stuff like LINUX_VERSION_CODE or UTS_RELEASE with whatever unmae gives you. There are scores of example of how to do it right, without depending on what one has in /usr/src/linux. Luiz Question 3 is crutial for what I'm gonna suggest to OSS Luiz people. Before you wrote me, I was thinking of suggesting them Luiz to -I /usr/src/kernel-headers-`uname -r` in a debian system... Using grep in a case like this is evil. Ask them why they can't follow what the rest of kernel module writers are doing, namely, looking at uname(2), and comparing with LINUX_VERSION_CODE or UTS_RELEASE. manoj -- Life sucks, but death doesn't put out at all Thomas J. Kopp Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
2.0.33 is no good for lic6-dev ?
Hi, folks. Why does libc6-dev depend on kernel headers from 2.0.32? I have all the 2.0.33 stuff properly installed, but cannot uninstall 2.0.32 kernel headers because of this :^ nr# dpkg --no-act --purge kernel-headers-2.0.32 dpkg: dependency problems prevent removal of kernel-headers-2.0.32: libc6-dev depends on kernel-headers-2.0.32 (= 2.0.32-2). dpkg: error processing kernel-headers-2.0.32 (--purge): dependency problems - not removing Errors were encountered while processing: kernel-headers-2.0.32 nr# dpkg -l libc6-dev Desired=Unknown/Install/Remove/Purge | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersionDescription +++-===-==- ii libc6-dev 2.0.7pre1-4The GNU C library version 2 (development fil Thanks! -- Luiz Otavio L. Zorzella Product Engineer [EMAIL PROTECTED] http://www.conexware.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.0.33 is no good for lic6-dev ?
Hi,
Please read /usr/doc/kernel-headers-2.0.32/debian.README.gz. I
have included a copy below for anyone who thinks reading stuff out of
/usr/doc is way square and uncool.
manoj
--
Sink or swim, live or die, survive or perish, I give my heart and my
hand to this vote. -- Daniel Webster
Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
$Id: README.headers,v 1.4 1998/01/30 01:26:20 srivasta Exp $
This is the Debian GNU/Linux prepackaged version of the Linux kernel
headers. Linux was written by Linus Torvalds
[EMAIL PROTECTED] and others.
This package was put together by Simon Shapiro [EMAIL PROTECTED], from
sources retrieved from directories under
ftp.cs.helsinki.fi:/pub/Software/Linux/Kernel/
This package contains the Linux kernel header files.
Kernel Headers and libc6-dev package
Need for kernel include files
=== == === =
Even though GNU libc 2.0 (a.k.a. libc6) provides an uniform
interface to C programmers, one should realize that it needs
different underpinnings on different architectures and operating
systems (remember, glibc2 is multi-OS).
glibc provides all the standard files that the C standard and
POSIX require, and those in turn call in OS and platform specific
headers as required transparently to the user. There is an a complete
divorce of the kernel-level interface from the user-level interface:
the application programmer does not need to know kernel level details
at all.
But this has been taken by some to mean that
/usr/include/{linux,asm} would be superfluous, which is a technical
impossibility given that glibc2 is not an architecture and OS
specific library.
I do not believe it is easy for glibc to present an interface
that does not match the underlying OS, and quite possibly people just
punted. If there is a mismatch between the user level structures and
the kernel level structures, then libc6 library shall have to install
translating wrappers around system calls (not such a great idea for
high performance systems). I can foresee cases where it would not be
possible to implement these wrappers, given a sufficiently large set
of architectures and OS's.
In the case of Linux, the kernel header files are the
underpinnings of the architecture independent interface.
Take a simple general ANSI C include file like errno.h. This
in turn includes /usr/include/errnos.h, which includes
/usr/include/linux/errno.h, which in turn includes
/usr/include/asm/errno.h. See? A simple, standard include file like
errno.h, and one needs kernel include files for that.
Traditional two symlink approach
=== === ===
Under libc5, it was standard for part of the user interface to
libc to be exported from the kernel includes, via /usr/include/linux
and /usr/include/asm. Traditionally, this was done by linking those
two directories to the appropriate directories in
/usr/src/linux/include. This is the method documented in the install
instructions for the kernel sources, even today.
Why that is bad
=== == ===
Kernel headers no longer make sense exporting to user space
(in early days of Linux, that was not true). It is beginning to get
harder to synchronize the libc and the kernel headers as in the old
days; now linking with the latest kernel headers may subtly break new
code since the headers linked with are different from the compiled
library. In addition, the specter of programs breaking with new
kernel headers was preventing needed new features from being added to
the kernel (and damping innovative experimentation in kernel
development) (see appendix A for details).
Besides, the kernel itself no longer needs /usr/include/linux/*
at all, so keeping the libc and kernel headers the same aren't
needed for kernel development.
The headers were included in Debian's libc5-dev after a rash
of very buggy alpha kernel releases (1.3.7* or something like that)
that proceeded to break compilations, etc. Kernel versions are
changed far more rapidly than libc is, and there are higher chances
that people install a custom kernel than they install custom libc.
Add to that the fact that few programs really need the more
volatile elements of the header files (that is, things that really
change from kernel version to kernel version), [before you reject
this, consider: programs compiled on one kernel version usually work
on other kernels]. For the few that do need specific kernel headers,
use -I/usr/src/kernel-headers-version or some thing for
Re: 2.0.33 is no good for lic6-dev ?
Manoj Srivastava writes: Hi, Please read /usr/doc/kernel-headers-2.0.32/debian.README.gz. I have included a copy below for anyone who thinks reading stuff out of /usr/doc is way square and uncool. Thanks for the article. Very cool indeed. Now, I'm running into a problem that might be related to this 2.0.32 headers (which was the reason I wanted to get rid of them). Maybe you can help on this. I have a OSS license -- the non-kernel sound card modules. Even though I'm pretty sure mostly everyone knows what I'm talking about, here it goes: http://www.4front-tech.com/linux.html After I upgraded my kernel to 2.0.33 (I believe, even though I'm not sure), I started having problems trying to install the OSS files in my system. It needs to compile a sndshield which is very attached to the kernel version. Here it goes (coments after --*-- marks): nr# make clean nr# make install sh ./check_shields.sh cc -D__KERNEL__ -DMODULE -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -DMODVERSIONS -c sndshield.c -o sndshield cp sndshield ./modules --*-- It links to /usr/src/linux, which is 2.0.33: nr# ls -l /usr/src/linux lrwxrwxrwx 1 root src20 May 13 14:54 /usr/src/linux - kernel-source-2.0.33 --*-- in a system that is 2.0.33: nr# uname -a Linux nr 2.0.33 #2 Sun May 10 16:44:29 EST 1998 i586 unknown --*-- But, as a Debian, has the 2.0.32 stuff: nr# ls -ld /usr/src/kernel* drwxr-xr-x 3 root root 1024 Mar 12 07:54 /usr/src/kernel-headers-2.0.32 drwxr-xr-x 3 root root 1024 Mar 10 08:00 /usr/src/kernel-headers-2.0.33 drwxr-xr-x 15 root root 1024 May 13 14:52 /usr/src/kernel-source-2.0.33 --*-- Now, when I try to execute soundon, it fails: nr# soundon Loading sndshield failed. You may try to execute the following commands to fix the situation: cd /usr/local/lib/oss;make install If loading sndshield still fails after that, please contact [EMAIL PROTECTED] for help (enclose the soundon.log file and possible (make/compile) errors with your message). --*-- And examining the log, I find that it thinks sndshield was compiled --*-- against 2.0.32. Is this related to the kernel-headers 2.0.32? Is there --*-- a -I or something I could use to fix it? nr# cat soundon.log Fri May 15 12:20:03 PDT 1998 Linux nr 2.0.33 #2 Sun May 10 16:44:29 EST 1998 i586 unknown This version (3.9b-980514) is compiled for Linux-2.0.33 Kernel version: Linux nr 2.0.33 #2 Sun May 10 16:44:29 EST 1998 i586 unknown Modutils version: 2.1.71 === Running /usr/local/bin/soundon === Install directory: /usr/local/lib/oss /usr/local/lib/oss/modules/sndshield: kernel-module version mismatch /usr/local/lib/oss/modules/sndshield was compiled for kernel version 2.0.32 while this kernel is version 2.0.33. Loading sndshield failed. Thanks a lot. -- Luiz Otavio L. Zorzella Product Engineer [EMAIL PROTECTED] http://www.conexware.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.0.33 is no good for lic6-dev ?
Hi, Hmm. if you use -I/usr/src/linux/include, then as far as I can see; it should link with those files (as you state further, it is linked to kernel-source-2.0.33). What toerh files you happen to have elsewhere should not make a difference. How is sndshield getting to know about 2.0.32? Well, try putting in -I/usr/src/linux/include for every file compiled in the tree; and see if that improves things. At the last resort, you can try mkdir /usr/src/tmp; mv the 2.0.32 headers there, and create a symlink from kernel-source-2.0.33 to kernel-headers-2.0.32; compile the module, and restore things to the way they were for the other 99.99% of the code that is well behaved (or less dependent on kernel versions). manoj -- After the correction has been found to be in error, it will be impossible to fit the original quantity back into the equation. --anonymous Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
